TDD. Когда вы можете двигаться дальше?

Question

При выполнении TDD , как сказать "достаточно тестов для этого класса / функции"?

т.е. когда вы могли бы сказать, что завершили тестирование всех крайних случаев?

Answer 1

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

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

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

Answer 2

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

Answer 3

На каком-то уровне это внутреннее чувство

«Уверен ли я, что тесты поймут все проблемы, о которых я могу думать? сейчас? "

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

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

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

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

Answer 4

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

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

Answer 5

Тест - это способ точного описания того, что вы хотите. Добавление теста расширяет область действия того, что вы хотите, или добавляет детали того, что вы хотите.

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

Answer 6

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

Только не забывайте, что если вы обнаружите ошибку позже, сначала напишите тест, чтобы воспроизвести ошибку, а затем исправьте ее, чтобы предотвратить повторное изменение в будущем!

Некоторые люди жалуются, что у них нет Х процентов покрытия .... некоторые тесты бесполезны, и 100% покрытие не означает, что вы тестируете все, что может сделать ваш код неработоспособным, только тот факт, что он не сломается как ты это использовал!

Answer 7

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

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

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

Answer 8

Многие другие комментарии ударили по голове. Чувствуете ли вы себя уверенно в коде, который вы написали для вашего теста? По мере развития вашего кода ваши тесты все еще адекватно охватывают его? Собирают ли ваши тесты предполагаемое поведение и функциональность для тестируемого компонента?

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

Я не собираюсь лгать, но я часто ленюсь, когда возвращаюсь, чтобы написать дополнительные тесты. Я мог бы пропустить это свойство, которое содержит 0 кода или конструктор по умолчанию, который меня не волнует. Иногда отсутствие полного анализа процесса может сэкономить ваше время в n областях, которые менее критичны (миф о 100% охвате кода).

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

Удачи и удачного кодирования.

Answer 9

Теоретически вы должны охватить все возможные комбинации входных данных и проверить правильность выходных данных, но иногда это просто не стоит.

Answer 10

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

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

С уважением