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

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

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

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

Ответ 1

Некоторые хорошие комментарии здесь, но я думаю, что одна вещь игнорируется.

Написание тестов сначала управляет вашим дизайном. Это важный шаг. Если вы пишете тесты "в одно и то же время" или "вскоре после", возможно, вам не хватает некоторых преимуществ разработки TDD в микрошагах.

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

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

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

Ответ 2

Были исследования, которые показывают, что модульные тесты, написанные после написания кода, являются лучшими тестами. Однако предостережение состоит в том, что люди не склонны писать их после события. Таким образом, TDD является хорошим компромиссом, поскольку, по крайней мере, тесты записываются.

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

Я стараюсь найти, что я делаю смесь. Чем больше я понимаю требования, тем больше тестов я могу написать вперед. Когда требования - или мое понимание проблемы - слабы, я, как правило, пишу тесты после этого.

Ответ 3

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

Итак, мой голос: Сначала проверьте

PS: И нет, это не значит, что вам не нужно планировать свою архитектуру раньше, но вы можете переосмыслить ее, если тесты скажут вам об этом!!!!

Ответ 4

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

Test Driven Development (TDD) помогает нам ответить "Что?" прежде чем мы ответим "Как?". и это имеет большое значение.

Я понимаю, почему могут возникнуть опасения по поводу несоблюдения этого в PoC-типе разработки/работы архитектора. И вы правы, что это может не иметь смысла следовать этому процессу. В то же время я хотел бы подчеркнуть, что TDD - это процесс, который входит в фазу разработки (я знаю, что это звучит устаревшим, но вы получаете точку:), когда спецификация низкого уровня понятна.

Ответ 5

Не всегда, но я считаю, что это действительно помогает, когда я это делаю.

Ответ 6

Я стараюсь писать их, когда пишу свой код. В лучшем случае я напишу тесты, если класс/модуль существует до того, как я его напишу.

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

Я не знаю, является ли это недостатком в моем мышлении или методе или просто TIMTOWTDI.

Ответ 7

Начну с того, как я хотел бы назвать свое "подразделение" и сделать его компиляцией. как:

picker = Pick.new
item=picker.pick('a')
assert item

тогда я создаю

class Pick
 def pick(something)
 return nil
 end
end

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

Итак, короче. Да. Соотношение, выполняющее тест раньше, намного выше, чем не делает.

Ответ 8

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

Ответ 9

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

Здесь мой компромисс по делу, и я нашел его весьма полезным и продуктивным.

Обычно самая сложная часть для правильного выбора - это требования и прямо за ним удобство использования вашего класса, API, пакета... Тогда это реальная реализация.

Напишите свои интерфейсы (они будут меняться, но пройдут долгий путь в знании WHAT)
Напишите простую программу для использования интерфейсов (их глупое главное). Это долгий путь в определении HOW, который будет использоваться (вернитесь к 1 как можно чаще)
Запишите тесты на интерфейсе (бит, который я интегрировал из TDD, снова возвращайтесь к 1 так часто, как нужно)
написать фактический код за интерфейсами
пишите тесты на классы и фактическую реализацию, используйте инструмент охвата, чтобы убедиться, что вы не забыли пути выполнения weid

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

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

Это строго говоря TDD? Экстремальный? Проворный...? без разницы...? Я не знаю, и, честно говоря, мне все равно. Он работает для меня. Я настраиваю его по мере необходимости и по мере развития моего понимания практики разработки программного обеспечения.

мой 2 цента

Ответ 10

Я программировал в течение 20 лет, и я практически никогда не писал строку кода, в которой я не запускал какой-то unit test on - Честно говоря, я знаю, что люди делают это все время, но как кто-то может отправить строку кода, которая не провела какой-то пробный прогон, находится вне меня.

Часто, если нет тестовой среды, я просто пишу main() в каждый класс, который я пишу. Он добавляет немного кружится в вашем приложении, но кто-то всегда может удалить его (или прокомментировать), если они захотят, я думаю. Мне очень жаль, что в вашем классе не было только метода test(), который автоматически компилируется для релизов - мне нравится, что мой тестовый метод находится в том же файле, что и мой код...

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

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

С другой стороны, когда вы добавляете существующий код и знаете точно, что именно вы хотите, он подбрасывает. Ваш "Другой код" часто проверяет ваш новый код на месте. Вам все равно нужно быть уверенным, что вы тестируете каждый путь, но вы получаете хороший охват, просто запустив тесты из внешнего интерфейса (кроме динамических языков - для тех, кому вы действительно должны иметь модульные тесты для всего, что бы ни было).

Кстати, когда у меня был довольно большой проект Ruby/Rails, у нас было очень высокое% охвата тестирования. Мы реорганизовали основной, центральный модельный класс на два класса. Это заняло бы нас два дня, но со всеми тестами, которые нам пришлось реорганизовать, он оказался ближе к двум неделям. Тесты НЕ полностью бесплатны.

Ответ 11

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

Ответ 12

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

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

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

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

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

Ответ 13

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

написать один минимальный тест
сделать тестовый проход, написав минимальный производственный код, необходимый
напишите следующий тест, который будет терпеть неудачу
выполнить все существующие тесты путем изменения существующего производственного кода самым простым способом.
реорганизуйте код (как тестовое, так и производственное!), чтобы он не содержал дублирования и выразителен
продолжайте с 3. пока вы не сможете придумать другой разумный тест.

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

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

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

Ответ 14

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

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

Самое смешное, если они начнут спорить "Я не уверен в этом первом испытании, но я никогда не делал этого так"... отлично...

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

Ответ 15

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

Ответ 16

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

Вы можете начать с "Истории", которые могут быть чем-то вроде

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

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

"Пользовательский класс имеет имя DOB-адрес TelNo Locked Fields"

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

Лукавая

Ответ 17

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

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

Ответ 18

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

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

Ответ 19

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

Ответ 20

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