Если вы посмотрите на любую ссылку на развитие, управляемое поведением, вы обнаружите использование таких фраз, как «BDD является производным от TDD», «BDD и TDD». Чтобы знать, как появился BDD, почему он называется производным от TDD и что такое BDD и TDD, необходимо иметь представление о TDD.
Зачем тестировать?
Для начала давайте разберемся с основами тестирования. Цель тестирования — убедиться, что построенная система работает должным образом. Рассмотрим следующий пример.
Таким образом, по опыту мы узнали, что выявление дефекта по мере его появления и немедленное его устранение будет экономически эффективным. Поэтому на каждом этапе разработки и тестирования необходимо писать тестовые примеры. Это то, чему нас научили наши традиционные методы тестирования, которые часто называют «Ранний тест».
Этот подход к тестированию называется подходом Test-Last, поскольку тестирование проводится после завершения этапа.
Проблемы с подходом Test-Last
Подход Test-Last использовался довольно долго в проектах по разработке программного обеспечения. Однако в действительности, при таком подходе, так как тестирование должно ждать завершения определенного этапа, часто его упускают из-за —
-
Задержки в завершении этапа.
-
Жесткие графики.
-
Сосредоточиться на доставке вовремя, пропуская тестирование.
Задержки в завершении этапа.
Жесткие графики.
Сосредоточиться на доставке вовремя, пропуская тестирование.
Кроме того, в подходе Test-Last модульное тестирование, которое должно выполняться разработчиками, часто пропускается. Различные причины основаны на мышлении разработчиков —
-
Они разработчики, а не тестеры.
-
Тестирование является обязанностью тестировщиков.
-
Они эффективны в кодировании, и их код не будет иметь дефектов.
Они разработчики, а не тестеры.
Тестирование является обязанностью тестировщиков.
Они эффективны в кодировании, и их код не будет иметь дефектов.
Это приводит к —
-
Компромат на качество поставляемой продукции.
-
Ответственность за качество только на тестерах.
-
Высокие затраты на устранение дефектов, почтовую доставку.
-
Неспособность получить удовлетворение клиента, что также означало бы потерю повторного бизнеса, таким образом влияя на вероятность.
Компромат на качество поставляемой продукции.
Ответственность за качество только на тестерах.
Высокие затраты на устранение дефектов, почтовую доставку.
Неспособность получить удовлетворение клиента, что также означало бы потерю повторного бизнеса, таким образом влияя на вероятность.
Эти факторы требовали изменения парадигмы, чтобы сосредоточиться на тестировании. Результатом стал подход Test-First.
Тест-первый подход
Подход Test-First заменяет наизнанку (запись кода, а затем тестирование) на разработку извне (запись, а затем код).
Этот подход включен в следующие методологии разработки программного обеспечения (которые также являются гибкими) —
-
e X treme P программирование ( XP ).
-
Тестирование развития (TDD).
e X treme P программирование ( XP ).
Тестирование развития (TDD).
В этих методологиях разработчик разрабатывает и пишет модульные тесты для модуля кода, прежде чем писать одну строку модуля кода. Затем разработчик создает модуль кода с целью прохождения модульного теста. Таким образом, эти методологии используют модульное тестирование для управления разработкой.
Необходимо отметить, что целью является разработка на основе тестирования.
Красный-Зеленый-Реактор Цикл
Разработка через тестирование используется для разработки кода, основанного на модульных тестах.
Шаг 1 — Рассмотрим модуль кода, который должен быть написан.
Шаг 2 — Написать тест
Шаг 3 — Запустите тест.
Тест не пройден, так как код все еще не написан. Следовательно, Шаг 2 обычно называется «написать тест на неудачу».
Шаг 4 — Напишите минимально возможный код, чтобы пройти тест.
Шаг 5 — Запустите все тесты, чтобы убедиться, что они все еще проходят. Модульные тесты автоматизированы, чтобы облегчить этот шаг.
Шаг 6 — Рефакторинг.
Шаг 7 — Повторите шаги с 1 по 6 для следующего модуля кода.
Каждый цикл должен быть очень коротким, а типичный час должен содержать много циклов.
Это также широко известно как цикл Red-Green-Refactor , где —
-
Красный — написание теста, который не проходит.
-
Зеленый — Написание кода для прохождения теста.
-
Refactor — Устранить дублирование и улучшить код до приемлемых стандартов.
Красный — написание теста, который не проходит.
Зеленый — Написание кода для прохождения теста.
Refactor — Устранить дублирование и улучшить код до приемлемых стандартов.
Шаги процесса TDD
Этапы процесса TDD проиллюстрированы ниже.
Преимущества TDD
Преимущества или преимущества Test Driven Development — это
-
Разработчик должен сначала понять, каким должен быть желаемый результат и как его протестировать перед созданием кода.
-
Код для компонента завершается только тогда, когда тест пройден и код подвергается рефакторингу. Это гарантирует тестирование и рефакторинг, прежде чем разработчик перейдет к следующему тесту.
-
Поскольку набор юнит-тестов запускается после каждого рефакторинга, обратная связь о том, что каждый компонент все еще работает, является постоянной.
-
Модульные тесты действуют как живая документация, которая всегда соответствует данным.
-
Если дефект обнаружен, разработчик создает тест, чтобы выявить этот дефект, а затем изменить код так, чтобы тест прошел, и дефект был исправлен. Это сокращает время отладки. Все остальные тесты также запускаются, и когда они проходят, это гарантирует, что существующая функциональность не нарушена
-
Разработчик может принимать проектные решения и проводить рефакторинг в любое время, а выполнение тестов гарантирует, что система все еще работает. Это делает программное обеспечение ремонтопригодным.
-
Разработчик уверен, что может внести любые изменения, поскольку, если изменение влияет на любую существующую функциональность, то же самое обнаруживается при запуске тестов, и дефекты могут быть немедленно исправлены.
-
При каждом последующем тестовом прогоне все предыдущие исправления дефектов также проверяются, и повторение одного и того же дефекта уменьшается.
-
Поскольку большая часть тестирования выполняется во время самой разработки, тестирование перед доставкой сокращается.
Разработчик должен сначала понять, каким должен быть желаемый результат и как его протестировать перед созданием кода.
Код для компонента завершается только тогда, когда тест пройден и код подвергается рефакторингу. Это гарантирует тестирование и рефакторинг, прежде чем разработчик перейдет к следующему тесту.
Поскольку набор юнит-тестов запускается после каждого рефакторинга, обратная связь о том, что каждый компонент все еще работает, является постоянной.
Модульные тесты действуют как живая документация, которая всегда соответствует данным.
Если дефект обнаружен, разработчик создает тест, чтобы выявить этот дефект, а затем изменить код так, чтобы тест прошел, и дефект был исправлен. Это сокращает время отладки. Все остальные тесты также запускаются, и когда они проходят, это гарантирует, что существующая функциональность не нарушена
Разработчик может принимать проектные решения и проводить рефакторинг в любое время, а выполнение тестов гарантирует, что система все еще работает. Это делает программное обеспечение ремонтопригодным.
Разработчик уверен, что может внести любые изменения, поскольку, если изменение влияет на любую существующую функциональность, то же самое обнаруживается при запуске тестов, и дефекты могут быть немедленно исправлены.
При каждом последующем тестовом прогоне все предыдущие исправления дефектов также проверяются, и повторение одного и того же дефекта уменьшается.
Поскольку большая часть тестирования выполняется во время самой разработки, тестирование перед доставкой сокращается.
Недостатки TDD
Отправной точкой являются пользовательские истории, описывающие поведение системы. Следовательно, разработчики часто сталкиваются со следующими вопросами —
-
Когда тестировать?
-
Что проверить?
-
Как узнать, соответствует ли спецификация?
-
Предоставляет ли код ценность для бизнеса?
Когда тестировать?
Что проверить?
Как узнать, соответствует ли спецификация?
Предоставляет ли код ценность для бизнеса?
Заблуждения о TDD
Следующие заблуждения существуют в отрасли и нуждаются в разъяснениях.
| неправильное представление | осветление |
|---|---|
| TDD — это все о тестировании и автоматизации тестирования. | TDD — это методология разработки с использованием подхода Test-First. |
| TDD не предполагает никакого дизайна. | TDD включает критический анализ и проектирование на основе требований. Дизайн появляется в процессе разработки. |
| TDD только на уровне блока. | TDD можно использовать на уровне интеграции и системы. |
| TDD не может использоваться традиционными проектами тестирования. | TDD стал популярным среди экстремального программирования и используется в других гибких методологиях. Однако его можно использовать и в традиционных проектах тестирования. |
| TDD это инструмент. |
TDD — это методология разработки, и после каждого нового модульного теста он добавляется в Automation Test Suite, поскольку все тесты необходимо запускать при добавлении нового кода или изменении существующего кода, а также после каждого рефакторинга. Таким образом, средства автоматизации тестирования, поддерживающие TDD, облегчают этот процесс. |
| TDD означает передачу приемочных тестов разработчикам. | TDD не означает сдачу приемочных тестов разработчикам. |
TDD — это методология разработки, и после каждого нового модульного теста он добавляется в Automation Test Suite, поскольку все тесты необходимо запускать при добавлении нового кода или изменении существующего кода, а также после каждого рефакторинга.
Таким образом, средства автоматизации тестирования, поддерживающие TDD, облегчают этот процесс.
Принятие TDD
Acceptance Test Driven Development (ATDD) определяет критерии приемки и приемочные тесты во время создания пользовательских историй на ранних стадиях разработки. ATDD фокусируется на коммуникации и взаимопонимании между заказчиками, разработчиками и тестировщиками.
Ключевые практики в ATDD следующие:
-
Обсудите реальные сценарии, чтобы построить общее понимание предметной области.
-
Используйте эти сценарии, чтобы прийти к критериям приемлемости.
-
Автоматизировать приемочные испытания.
-
Сосредоточьте разработку на этих тестах.
-
Используйте тесты как живую спецификацию для облегчения изменений.
Обсудите реальные сценарии, чтобы построить общее понимание предметной области.
Используйте эти сценарии, чтобы прийти к критериям приемлемости.
Автоматизировать приемочные испытания.
Сосредоточьте разработку на этих тестах.
Используйте тесты как живую спецификацию для облегчения изменений.
Преимущества использования ATDD следующие:
-
Требования однозначны и не имеют функциональных пробелов.
-
Другие понимают особые случаи, которые предвидят разработчики.
-
Приемочные тесты направляют разработку.
Требования однозначны и не имеют функциональных пробелов.
Другие понимают особые случаи, которые предвидят разработчики.
Приемочные тесты направляют разработку.
TDD против BDD
По словам Дэна Норта, программисты обычно сталкиваются со следующими проблемами при выполнении тестовой разработки —
-
Когда начать
-
Что проверять, а что не проверять
-
Сколько тестировать за один раз
-
Как назвать свои тесты
-
Как понять, почему тест не пройден
Когда начать
Что проверять, а что не проверять
Сколько тестировать за один раз
Как назвать свои тесты
Как понять, почему тест не пройден
Решением всех этих проблем является развитие, управляемое поведением. Он развился из установленных гибких практик и призван сделать их более доступными и эффективными для групп, новичков в гибкой доставке программного обеспечения. Со временем BDD расширился, чтобы охватить более широкую картину гибкого анализа и автоматического приемочного тестирования.
Основное различие между TDD и BDD заключается в том, что —
TDD описывает, как работает программное обеспечение.
С другой стороны, BDD —
Описывает, как конечный пользователь использует программное обеспечение.
Способствует сотрудничеству и общению.
Подчеркивает на примерах поведения Системы.
Цели в исполняемых спецификациях, полученных из примеров