Test-driven development

«Разработка, управляемая тестированием» (Test-driven development) – стиль программирования, где тесно взаимодействуют кодирование, тестирование (в форме написания модульных тестов) и дизайн (в форме рефакторинга).

Этот стиль можно кратко описать следующим набором правил:

• написать «один» модульный тест, описывающий аспект программы
• запустить тест, который не должен пройти из-за отсутствия функции в программе
• написать «достаточно» кода, простейшего, чтобы тест пройдет
• «рефакторить» код до соответствия критериям простоты
• повторять, «наращивая» модульные тесты со временем

Ожидаемые преимущества

многие команды сообщают о существенном снижении дефектности, за счет умеренного увеличения начальных усилий эти команды также отмечают, что эти накладные расходы более чем окупаются сокращением усилий на последних этапах проектов хотя эмпирические исследования пока не подтверждают это, опытные практики сообщают, что TDD приводит к улучшению дизайна кода и более высокому уровню «внутреннего» или технического качества, например, улучшению показателей связности и связывания Общие ошибки Типичные ошибки отдельных лиц включают:

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

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

Происхождение

Хотя идея того, чтобы тестирование предшествовало программированию, не является оригинальной для Agile-сообщества, TDD представляет собой прорыв, объединяя эту идею с идеей «тестирования разработчика».

1976

публикация «Software Reliability» Гленфордом Майерсом, где считается, что «разработчик не должен тестировать свой собственный код» (Темные века тестирования разработчиков)

1990

дисциплина тестирования доминируется «черными ящиками», в частности в виде инструментов тестирования «захват и воспроизведение»

1991

независимое создание тестового фреймворка в Taligent с удивительными сходствами с SUnit (источник)

1994

Кент Бек пишет тестовый фреймворк SUnit для Smalltalk (источник)

1998

статья об Extreme Programming упоминает, что «мы обычно сначала пишем тест» (источник)

1998–2002

«Сначала тест» развивается в «Тестовое разработанное», в частности на C2.com Wiki

2000

Mock Objects – одна из новых техник, разработанных в этот период (источник)

2003

публикация «Разработка, управляемая тестированием: на примере» Кента Бека

К 2006 году TDD – относительно зрелая дисциплина, которая начала поощрять дальнейшие инновации, произошедшие от нее, такие как ATDD или BDD).

Признаки использования Test-Driven Development

• «покрытие кода» – общий способ подтверждения использования TDD; хотя высокое покрытие не гарантирует правильного использования TDD, покрытие менее 80% вероятно указывает на недостатки в владении командой TDD
• журналы управления версиями должны показывать, что код теста проверяется каждый раз, когда проверяется код продукта, примерно в одинаковом объеме

Уровни навыков

Новичок

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

Средний

• практикует «тестовое управление исправлением ошибок»: при обнаружении дефекта пишет тест, выявляющий дефект перед исправлением
• умеет разложить сложный элемент программы на последовательность нескольких модульных тестов
• знает и может назвать ряд тактик для написания тестов (например, «при тестировании рекурсивного алгоритма сначала напишите тест для случая завершения рекурсии»)
• умеет выделить повторно используемые элементы из существующих модульных тестов, создавая ситуационно специфичные инструменты тестирования

Продвинутый

• способен сформулировать «дорожную карту» запланированных модульных тестов для макроскопических функций (и пересматривать ее по мере необходимости)
• способен «тестировать водитель» различные парадигмы проектирования: объектно-ориентированные, функциональные, событийно-ориентированные
• способен «тестировать водитель» различные технические области: вычисления, пользовательские интерфейсы, доступ к постоянным данным…