Каковы некоторые распространенные недоразумения о TDD?

Question

Чтение ответов на этот вопрос Недостатки разработки через тестирование? У меня сложилось впечатление, что существует много недоразумений о том, что такое TDD и как его следует проводить. Здесь может оказаться полезным решить эти проблемы.

Answer 1

Мне кажется, что принятый ответ был одним из самых слабых ( Недостатки разработки, управляемой тестами? ), и самый модный ответ пахнет кем-то, кто может писать над определенными тестами.

Большие инвестиции времени: для простых если вы потеряете около 20% от фактического реализация, но для сложных случаев вы теряете гораздо больше.

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

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

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

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

Это худший из них! TDD действительно должен быть «Test Driven Design ». TDD - это дизайн, а не тестирование. Чтобы в полной мере осознать все преимущества TDD, у вас есть игрушка drive вашего дизайна из ваших тестов. Таким образом, вы должны переделать свой производственный код, чтобы ваши тесты прошли, а не наоборот, как предполагает этот пункт

Сейчас самое модное на данный момент: Недостатки тестовой разработки?

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

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

Answer 2

ИМХО Самым большим заблуждением о TDD является то, что: время, потраченное на написание и рефакторинг тестов, будет потеряно. Мысль звучит так: «Да, набор тестов - это хорошо, но функция будет реализована намного быстрее если мы просто закодировали это ".

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

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

Answer 3

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

Другой крайностью является то, что люди перестают проводить приемочное тестирование и думают, что, поскольку они проводят модульное тестирование, их код тестируется. Это опять-таки неправильное понимание функции юнит-теста. Вам все еще нужны какие-то приемочные испытания.

Answer 4

Просто бросаю другой ответ в банке.

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

Почему? ..

Что ж, код, который легко проверить:

1. Модульный - каждый метод делает одно.
2. Параметризованный - каждый метод принимает все, что ему нужно, и выводит все, что должен.
3. Хорошо указано - каждый метод делает именно то, что должен, не больше, не меньше.

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

Лучше, чем в , читать , тестировать , понимать , отлаживать Вот почему TDD часто описывают как упражнение по проектированию.

Answer 5

Это вопросы, которые, на мой взгляд, довольно противоречивы и, следовательно, склонны к недопониманию:

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

• Люди, кажется, думают, что нужно протестировать только основное подмножество функций, но это на самом деле неправильно ИМХО. Вам нужно проверить все, чтобы ваш тест был действительным после рефакторинга.

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

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

Answer 6

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

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