38. Разработка через тестирование
Разработка через тестирование (TDD) – техника разработки ПО, которая основывается на повторении очень коротких циклов разработки следующего вида:
Сначала пишется тест, покрывающий желаемое изменение
Пишется код, реализующий это изменение и проходящий тест
Проводится рефакторинг нового кода
В 1999 г. Была выдвинута концепция test first. Впоследствии TDD выделилась как отдельная методология.
Терминология:
Модульный тест – тест, проверяющий функциональность отдельно взятого класса. Эти тесты не видны конечному пользователю или эксперту предметной области. Пишутся обычно после функциональных тестов.
Красная полоса – индикатор, который используется во многих графических средах для выполнения модульных тестов. Результат – выполнение теста отображается в виде линии
MOCK-объекты – автоматически генерируемые заглушки, которые могут выступать в роли реальных объектов. Поведением MOCK-ов можно управлять во время теста. MOCK-и могут выполнять доп. Проверки, что тестируемый код использует их как ожидается
Тест (test case) – набор тестовых методов, предназначенных для тестирования одного класса. Каждый такой метод тестирует какой-либо один объект тестируемого класса.
Фикстура – состояние среды тестирования, которое требуется для успешного выполнения тестового метода(наличие определенных файлов и т.д.). Во многих автоматических системах фикстура создается методом setup(), а удаляется с помощью метода teardown().
Проверка (assert) – метод класса, который предназначается для свёртки реального состояния кода с ожидаемым
Набор тестов (test suit) – набор тест кейсов, который предназначен для тестирования какой-либо укрупнённой сущности.
В рамках методики TDD рассматриваются 2 шага:
Писать новый код только тогда, когда автоматический тест не пройден
Удалять дублирование в написании кода
TDD предполагает, что система строится из сильносвязанных модулей, слабо связанных друг с другом.
Порядок работы:
Красный шаг – написать небольшой тест, который не работает, а возможно даже не компилируется. Чтобы написать тест, разработчик должен чётко понимать требования для новой функциональности.
Нужно запустить всё тесты и убедиться, что они не проходят
Зелёный шаг – заставить тест работать как можно быстрее, при этом не нудно думать о правильности дизайна и чистоте кода. Важно писать код, предназначенный именно для прохождения теста.
Запуск всех тестов. Надо убедиться, что все тесты проходят
Рефакторинг – проводится чистка кода
Теперь цикл можно повторить.
При использовании сторонних библиотек их тестирование должно проводиться отдельно.
Рекомендации:
Тесты должны быть понятными
К коду тестов следует применять те же тесты, что и к основному коду
Ассерты следует снабжать параметрами-комментариями
Хорошо написанные тесты – это пособие по тому, как можно использовать код
Необходимо минимизировать кол-во классов и методов, необходимых для одного тестового метода
Если тест громоздкий, то скорее всего с тестируемым кодом не всё нормально
Тесты должны проверять большинство пограничных ситуаций
MOCK-объекты – это автоматически генерируемые заглушки, которые позволяют имитировать некую функциональность и управлять ею прямо из теста. Они создаются на базе каких-либо интерфейсов или классов. В этом случае MOCK поддерживает все методы интерфейса + методы по настройке и поведению МОКа.
Управление МОКами включает в себя:
Возврат определённых значений из метода при определенных условиях
Ожидание определённых выходов методов определённое кол-во раз
Учёт порядка вызова методов
Преимущества:
Позволяют на ранних этапах разработки проверять проект и разрабатывать его , имея на руках только интерфейсы, но не имея реальных классов
МОКи позволяют заметно ускорить исполнение тестов, изолируя ресурсоёмкие участки кода
Когда использовать:
Изоляция тестируемого кода от внешней среды
Процесс применения:
Везде, где требуется доступ к внешним ресурсам, должен быть объявлен интерфейс, через который этот доступ будет осуществляться
Интерфейс имеет 2 реализации:
- доступ к реальному ресурсу
- MOCK-объект
Ошибки использования TDD:
Должно быть правильное понимание ТДД
3 способа ведения тестов:
- традиционный – всё на тестах, активный рефакторинг, первычная реализация, сильно упрощённая
- активный – сначала обдумывается дизайн рабочего кода, а затем к этому дищайну идут через тесты
- приёмочник – сразу пишется конечный тест, который проверяет конечную функциональность
2) неправильное внедрение ТДД
3) ТДД- это не самоцель
Недостатки ТДД:
сложно привыкнуть
существуют задачи, которые сложно решить только при помощи тестов
ТДД буксует, когда необходимо прохождение функциональных тестов
Больше времени требуется на разработку