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

Question

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

На каком-то уровне это внутреннее ощущение

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

возможно, я где-то что-то упустил в мире Agile / XP, но мое понимание процесса заключалось в том, что разработчик и заказчик укажите тесты как часть Функции.Это позволяет тестовым примерам заменять более формальную документацию по требованиям, помогает определить варианты использования функции и т.д.Итак, вы закончили тестирование и кодирование, когда все эти тесты пройдены...плюс любые другие крайние случаи, о которых вы подумаете по пути

Answer 9

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

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

С наилучшими пожеланиями

Answer 10

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

Answer 11

Многие другие комментарии попали в самую точку.Уверены ли вы в написанном вами коде, учитывая ваше тестовое покрытие?По мере развития вашего кода ваши тесты по-прежнему адекватно покрывают его?Отражают ли ваши тесты предполагаемое поведение и функциональность тестируемого компонента?

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

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

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

Удачи и счастливого кодирования.

Answer 12

Вы всегда можете использовать инструмент тестового покрытия, такой как EMMA (http://emma.sourceforge.net/) или его плагин Eclipse EclEmma (http://www.eclemma.org/) или что-то подобное.Некоторые разработчики считают, что 100% охват тестированием - достойная цель;другие с этим не согласны.

Answer 13

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

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

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