38. Разработка через тестирование

Разработка через тестирование (TDD) – техника разработки ПО, которая основывается на повторении очень коротких циклов разработки следующего вида:

• Сначала пишется тест, покрывающий желаемое изменение

• Пишется код, реализующий это изменение и проходящий тест

• Проводится рефакторинг нового кода

В 1999 г. Была выдвинута концепция test first. Впоследствии TDD выделилась как отдельная методология.

Терминология:

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

• Красная полоса – индикатор, который используется во многих графических средах для выполнения модульных тестов. Результат – выполнение теста отображается в виде линии

• MOCK-объекты – автоматически генерируемые заглушки, которые могут выступать в роли реальных объектов. Поведением MOCK-ов можно управлять во время теста. MOCK-и могут выполнять доп. Проверки, что тестируемый код использует их как ожидается

• Тест (test case) – набор тестовых методов, предназначенных для тестирования одного класса. Каждый такой метод тестирует какой-либо один объект тестируемого класса.

• Фикстура – состояние среды тестирования, которое требуется для успешного выполнения тестового метода(наличие определенных файлов и т.д.). Во многих автоматических системах фикстура создается методом setup(), а удаляется с помощью метода teardown().

• Проверка (assert) – метод класса, который предназначается для свёртки реального состояния кода с ожидаемым

• Набор тестов (test suit) – набор тест кейсов, который предназначен для тестирования какой-либо укрупнённой сущности.

В рамках методики TDD рассматриваются 2 шага:

1. Писать новый код только тогда, когда автоматический тест не пройден

2. Удалять дублирование в написании кода

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

Порядок работы:

1. Красный шаг – написать небольшой тест, который не работает, а возможно даже не компилируется. Чтобы написать тест, разработчик должен чётко понимать требования для новой функциональности.

2. Нужно запустить всё тесты и убедиться, что они не проходят

3. Зелёный шаг – заставить тест работать как можно быстрее, при этом не нудно думать о правильности дизайна и чистоте кода. Важно писать код, предназначенный именно для прохождения теста.

4. Запуск всех тестов. Надо убедиться, что все тесты проходят

5. Рефакторинг – проводится чистка кода

Теперь цикл можно повторить.

При использовании сторонних библиотек их тестирование должно проводиться отдельно.

Рекомендации:

• Тесты должны быть понятными

• К коду тестов следует применять те же тесты, что и к основному коду

• Ассерты следует снабжать параметрами-комментариями

• Хорошо написанные тесты – это пособие по тому, как можно использовать код

• Необходимо минимизировать кол-во классов и методов, необходимых для одного тестового метода

• Если тест громоздкий, то скорее всего с тестируемым кодом не всё нормально

• Тесты должны проверять большинство пограничных ситуаций

MOCK-объекты – это автоматически генерируемые заглушки, которые позволяют имитировать некую функциональность и управлять ею прямо из теста. Они создаются на базе каких-либо интерфейсов или классов. В этом случае MOCK поддерживает все методы интерфейса + методы по настройке и поведению МОКа.

Управление МОКами включает в себя:

1. Возврат определённых значений из метода при определенных условиях

2. Ожидание определённых выходов методов определённое кол-во раз

3. Учёт порядка вызова методов

Преимущества:

1. Позволяют на ранних этапах разработки проверять проект и разрабатывать его , имея на руках только интерфейсы, но не имея реальных классов

2. МОКи позволяют заметно ускорить исполнение тестов, изолируя ресурсоёмкие участки кода

Когда использовать:

1. Изоляция тестируемого кода от внешней среды

Процесс применения:

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

2. Интерфейс имеет 2 реализации:

- доступ к реальному ресурсу

- MOCK-объект

Ошибки использования TDD:

1. Должно быть правильное понимание ТДД

3 способа ведения тестов:

- традиционный – всё на тестах, активный рефакторинг, первычная реализация, сильно упрощённая

- активный – сначала обдумывается дизайн рабочего кода, а затем к этому дищайну идут через тесты

- приёмочник – сразу пишется конечный тест, который проверяет конечную функциональность

2) неправильное внедрение ТДД

3) ТДД- это не самоцель

Недостатки ТДД:

1. сложно привыкнуть

2. существуют задачи, которые сложно решить только при помощи тестов

3. ТДД буксует, когда необходимо прохождение функциональных тестов

4. Больше времени требуется на разработку