Планирование юнит-тестов с TDD

Question

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

Answer 1

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

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

Посмотрите игру Боба Мартина *1007* в боулинг, которая должна дать вам больше ощущения от TDD.

Answer 2

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

По моему (по общему признанию, довольно новому) опыту

• Вы пишете тест, который, если он будет пройден, подтвердит ваше первоначальное понимание целевой функциональности.На данный момент не написано ни одной строки производственного кода.
• Затем вы реализуете производственный код, чтобы пройти модульные тесты.
• Если ваше понимание развивается, вы затем меняете свои модульные тесты или / и добавляете новые
• Затем вы вносите изменения в рабочий код, чтобы тесты проходили
• тогда не запрещено писать дополнительные модульные тесты, если вы обнаружите, что части вашего производственного кода не охвачены.
• Удалить тесты, которые больше не имеют смысла.
• Вы получите красивый четкий и чистый код: o)

TDD НЕ является методом обеспечения качества;Это способ РАЗВИТИЯ.Вся идея заключается в том, что модульное тестирование направляет процесс разработки.Таким образом, вы действительно не можете позволить другим делать за вас юнит-тесты.

Answer 3

TDD - это не та методология, которую вы ищете; -)

way to let other programmers/QAs know what tests should be implemented

Это утверждение подразумевает, что вы после испытаний, но само TDD определяется требованиями и предоставляет функции - тот факт, что оно также производитНабор тестов является случайным (но чрезвычайно мощным) дополнением, результатом которого является набор регрессий.

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

Кроме того, другим побочным эффектом TDD является наличие (и постоянная работа) набора регрессии.Если на более позднем этапе обнаружена ошибка, проще, имея набор тестов, написать другой тест , который демонстрирует ошибку с ошибочным тестом.Как только ошибка устранена, тест должен пройти - вместе с all другими тестами в наборе.

Answer 4

Я не думаю, что наличие шаблона хорошо сочетается с использованием TDD. Я предполагаю, что вы читали книгу Кента Бека «Разработка через тестирование на примере». Если нет, пожалуйста, сделайте это.

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

1. Имейте общее представление о классе ответственность и использовать это информация для названия класса.

2. Создать тестовый набор для этого класса.

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

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

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

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

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

Answer 5

Сначала я спроектирую класс, обычно с простой диаграммы классов UML.Я стараюсь не делать диаграмму достаточно детальной, чтобы можно было выполнять с ней тесты (например, параметры и возвращаемые типы, указанные для каждого метода, и я знаю, как поведение метода влияет на состояние объекта).

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

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