Должны ли модульные тесты быть написаны до написания кода?

Question

Я знаю, что одним из определяющих принципов разработки, управляемой тестами, является то, что вы сначала пишете свои модульные тесты, а затем пишете код для прохождения этих модульных тестов, но нужно ли это делать таким образом?

Я обнаружил, что часто не знаю, что я тестирую, пока не написал это, в основном потому, что последние несколько проектов, над которыми я работал, в большей степени развивались от проверки концепции, чем от разработки.

Я уже пытался написать свои модульные тесты, и это может быть полезно, но мне это не кажется естественным.

Answer 1

Сейчас так много ответов, и все они разные. Это очень похоже на реальность там. Все делают это по-своему. Я думаю, что существует огромное недопонимание о модульном тестировании. Мне кажется, что люди слышали о TDD и говорили, что это хорошо. Затем они начали писать модульные тесты, не понимая, что на самом деле является TDD. Они только что получили часть «о да, мы должны написать тесты», и они согласны с этим. Они также слышали об этом «сначала вы должны написать свои тесты», но они не воспринимают это всерьез.

Я думаю, это потому, что они не понимают преимуществ первого теста, который, в свою очередь, вы можете понять только после того, как проделали это таким образом в течение некоторого времени. И они всегда, кажется, находят 1.000.000 оправданий, почему им не нравится сначала писать тесты. Потому что слишком сложно понять, как все будет сочетаться и т.д. 1003 *

Самое смешное, если они начнут спорить: «Я не убежден в этом, прежде всего, в тесте, но я никогда так не делал» ... отлично ...

Интересно, откуда изначально пошло юнит-тестирование? Потому что, если концепция действительно происходит от TDD, просто смешно, как люди ошибаются.

Answer 2

Я не уверен, но из вашего описания я чувствую, что может быть неправильное понимание того, что на самом деле означает первый тест. не означает, что вы сначала пишете все свои тесты. Это означает, что у вас очень узкий цикл

1. написать один, минимальный тест
2. выполнить тестирование, написав необходимый минимальный производственный код
3. написать следующий тест, который не пройдёт
4. выполнить все существующие тесты, изменив существующий производственный код самым простым способом
5. рефакторинг кода (как тестового, так и рабочего!), Чтобы он не содержал дублирования и был выразительным
6. продолжайте с 3., пока вы не сможете придумать еще один разумный тест

Один цикл (3-5) обычно занимает пару минут. Используя эту технику, вы на самом деле развиваете дизайн, в то время как вы пишете свои тесты и производственный код параллельно. В этом не так много предварительного дизайна.

На вопрос о том, что это "необходимо" - нет, очевидно, это не так. Были бесчисленные проекты, успешные без выполнения TDD. Но есть некоторые убедительные доказательства того, что использование TDD обычно приводит к значительно более высокому качеству, часто без негативного влияния на производительность. И это тоже весело!

О, и, учитывая, что он не чувствует себя "естественным", это просто вопрос того, к чему вы привыкли. Я знаю людей, которые привыкли получать зеленую полосу (типичный знак xUnit для «прохождения всех тестов») каждые пару минут.

Answer 3

Написание тестов сначала определяет, как будет выглядеть ваш код - то есть он стремится сделать ваш код более модульным и тестируемым, поэтому вы не создаете «раздутые» методы с очень сложной и перекрывающейся функциональностью. Это также помогает изолировать все основные функции в отдельных методах для упрощения тестирования.

Answer 4

Лично я считаю, что модульные тесты теряют свою эффективность, если не будут выполнены до написания кода.

Вечная проблема с тестированием заключается в том, что, как бы мы ни старались, мы никогда не придумаем каждый возможный сценарий, чтобы написать тест для покрытия.

Очевидно, что сам по себе модульное тестирование не предотвращает этого полностью, так как оно ограничивает тестирование, рассматривая только один блок кода, не охватывающий взаимодействия между этим кодом и всем остальным, но оно обеспечивает хорошую основу для написания чистого кода в первом место, которое должно как минимум ограничивать шансы на проблемы взаимодействия между модулями. Я всегда работал над тем, чтобы сделать код как можно более простым - на самом деле, я считаю, что это один из ключевых принципов TDD.

Итак, начнем с теста, который в основном говорит, что вы можете создать класс такого типа и построить его теоретически, написав тест для каждой строки кода или, по крайней мере, охватывая каждый маршрут через определенный фрагмент кода. Проектирование, как вы идете! Очевидно, на основе грубого дизайна, созданного изначально, чтобы дать вам основу для работы.

Как вы говорите, это очень неестественно с самого начала и может показаться пустой тратой времени, но я воочию убедился, что в конечном итоге это окупается, когда просматриваются статистические данные о дефектах и ​​показывают модули, которые были полностью написанные с использованием TDD имеют гораздо меньше дефектов с течением времени, чем другие.

Answer 5

До, во время и после. Прежде чем является частью спецификации, контракта, определение работы В тех случаях, когда особые случаи, плохие данные, исключения обнаруживаются при реализации. После это обслуживание, эволюция, изменения, новые требования.

Answer 6

Это помогает, когда вы пишете что-то, что пишете, чтобы написать сначала все, что вы регулярно проверяете, а затем пишете эти функции. В большинстве случаев эти функции не являются наиболее важными для программного обеспечения, которое вы пишете. Теперь, с другой стороны, нет серебряных пуль, и никогда не следует следовать букве. Решение разработчика играет большую роль в решении использовать разработку, основанную на тестировании, а не тестирование последней разработки.

Answer 7

Сначала я не пишу фактические модульные тесты, но делаю тестовую матрицу, прежде чем приступить к кодированию, перечисляя все возможные сценарии, которые должны быть протестированы. Я также делаю список случаев, которые должны быть проверены при внесении изменений в любую часть программы в рамках регрессионного тестирования, которые будут охватывать большинство основных сценариев в приложении в дополнение к полному тестированию фрагмента кода, который измененное.

Answer 8

Помните, что при экстремальном программировании ваши тесты действительно являются вашей документацией. Так что если вы не знаете, что тестируете, то не знаете, что вы хотите, чтобы ваше приложение делало?

Вы можете начать с «Рассказов», которые могут быть что-то вроде

«Пользователи могут получить список вопросов»

Затем, когда вы начнете писать код для решения модульных тестов. Для решения вышесказанного вам понадобится как минимум класс пользователя и вопроса. Итак, вы можете начать думать о полях:

«Пользовательский класс имеет имя DOB Address TelNo Locked Fields»

и т.д.. Надеюсь, это поможет.

Хитрый

Answer 9

Да, если вы используете настоящие принципы TDD. В противном случае, пока вы пишете юнит-тесты, у вас дела идут лучше, чем у большинства.

По моему опыту, обычно легче писать тесты перед кодом, потому что, делая это таким образом, вы получаете простой инструмент отладки, который можно использовать при написании кода.

Answer 10

Я пишу их одновременно. Я создаю скелетный код для нового класса и тестового класса, а затем пишу тест для некоторой функциональности (который затем помогает мне понять, как я хочу вызывать новый объект) и внедряю его в код.

Обычно я не получаю элегантный код в первый раз, обычно он довольно хакерский. Но после того, как все тесты сработают, вы можете выполнить рефакторинг, пока не получите что-то довольно аккуратное, аккуратное и доказуемое, чтобы быть надежным.