Написание модульных тестов позже

Question

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

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

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

Я не совсем уверен, что это хороший подход ( определенно не лучший ).

Что вы думаете? Вы пишете код для написания своих модульных тестов позже? Или как вы справляетесь с этой проблемой потока или экспериментальным этапом проектирования / разработки кода.

Answer 1

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

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

Answer 2

Я написал тесты по факту. Лучше поздно, чем никогда. Их всегда стоит иметь.

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

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

Answer 3

«Я не совсем уверен, что это хороший подход (определенно, не самый лучший)».

Не хорошо? Почему бы и нет?

Вы разрабатываете для тестирования? В этом случае ваш дизайн основан на тестировании. Что еще можно попросить?

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

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

Answer 4

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

Если вы пишете тесты первыми ...

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

Если вы сначала напишите код ...

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

Хотя я был бы удивлен, если бы 1 программист из 50 ВСЕГДА писал тесты в первую очередь, я все равно утверждал бы, что к этому нужно стремиться, если вы хотите написать хорошее программное обеспечение.

Answer 5

Я бы сказал, что для нормальной разработки TDD работает очень хорошо. Существуют случаи, когда вам может не понадобиться сначала писать тесты (или даже вообще), но они нечасты. Иногда, однако, вам нужно сделать некоторые исследования, чтобы увидеть, что будет работать. Я бы посчитал это «всплеском», и я не обязательно думаю, что TDD абсолютно необходим в этом случае. Я бы, вероятно, не использовал реальный код «шип» в моем проекте. В конце концов, это было просто исследование, и теперь, когда у меня есть лучшее представление о том, как это должно работать, я, вероятно, могу написать лучший код (и тесты), чем мой «всплесковый» код. Если бы я решил использовать свой «всплесковый» код, я бы, вероятно, вернулся и написал для него тесты.

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

Answer 6

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

Answer 7

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

Answer 8

Я хотел бы сказать, что сначала я всегда пишу модульные тесты, но, конечно, я не пишу (по многим причинам, хорошо известным любому настоящему программисту :-)). То, что я (хорошо, также не всегда ...), - это преобразование каждой ошибки, которая занимает у меня более пяти минут, чтобы найти ее в модульном тесте. Еще до того, как я это исправлю. Это имеет следующие преимущества:

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

Answer 9

Написание кода сначала естественно, когда вы пытаетесь понять, как ваш код будет работать. Написание теста сначала поможет вам определить, что делает ваш код (не так, как он должен это делать). Если вы сначала пишете код, вы пытаетесь решить проблему без ее полного определения. Это не обязательно «плохо», но вы используете модульные тесты как инструмент регрессии, а не как инструмент разработки (опять же, не «плохо» - просто не TDD).

Answer 10

VS 2008 имеет приятную функцию, которая генерирует классы тестов для объекта, тесты должны быть доработаны, но это потребует много работы для вас. Это действительно хорошо для тестирования теста для ваших менее усердных коллег.

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

если вы используете другую среду тестирования, чем MSUnitTest, конвертировать тесты из MSUnit в Nunit и т. Д. Довольно просто, просто сделайте несколько копий и пройдите.