Разработка, управляемая тестами: как работает метод

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

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

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

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

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

Отдельные тестовые случаи обычно проходят через цикл не более нескольких секунд или минут. Таким образом, результаты можно быстро увидеть в работающем коде. Для эффективной итерации вам понадобится инструмент и фреймворк TDD. Обычно разработчики используют инструменты для автоматизации сборки, такие как CruiseControl или Jenkins. Они обеспечивают непрерывную и безупречную интеграцию компонентов в исходный код. JUnit, Maven и Ant также популярны в Java-разработке. Как правило, тесты всегда пишутся на том же языке, что и функционирующий код. Для PHP можно использовать такие инструменты, как Ceedling или CMock, например.

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

1. Красная фаза: В этой фазе учитывается точка зрения пользователя, что означает, что код должен быть простым. Другими словами, вы пишете тест, который содержит компоненты, которые еще не реализованы. Поэтому вам нужно принять решение о том, какие элементы необходимы для того, чтобы часть кода работала.
2. Зеленая фаза: Предположим, что тест провалился и помечен красным цветом. Теперь вы входите в роль программиста, который пытается найти простое решение. Самое главное, вы пишете только столько кода, сколько необходимо. Затем вы интегрируете его в работающий код так, чтобы тест был отмечен зеленым цветом.
3. Рефакторинг: На этом этапе работающий код «приводится в порядок» и совершенствуется в своей структуре. Это означает, что вы должны изменить и реструктурировать его таким образом, чтобы он стал простым и элегантным для чтения с точки зрения разработчика. Эти шаги включают, например, удаление дублирующегося кода.

Убедитесь, что отдельные действия не пересекаются, т.е. не пишите тесты на фазе 2 или 3 или функционирующий код на фазе 1 и 3. В следующем видеоролике показано, как тестоориентированная разработка работает на практике:

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

Разработка на основе тестов — это стратегия проектирования, которая направляет процесс разработки программного обеспечения с помощью различных тестов. В отличие от нисходящих методов, тест-кейсы в TDD являются частью дизайна программного обеспечения с самого начала. Тесты, используемые в TDD, различаются по назначению и масштабу. Самый простой тест — это модульный тест или юнит-тест. Он проверяет отдельные компоненты компьютерной программы. Интеграционные и функциональные тесты более сложны. Они используются для оценки взаимодействия различных частей системы и общей функциональности программы.

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

В таблице ниже кратко описаны преимущества и недостатки разработки на основе тестов:

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