Держим дизайн системы под контролем, используя изолированное юнит-тестированиеТестирование, A/B-тестирование

Доклад принят в программу конференции
Андрей Коломенский
self-emploed

In love with agile & experiments. TDD fanatic. Я являюсь экспертом в дисциплине Test Driven Development (TDD) и способен обучить разработчиков писать качественный код с нулевым количеством дефектов, что положительно сказывается на скорости поставки.

Тезисы

Код наших систем со временем загнивает из-за низкого качества обратной связи, которую дают интегрированные тесты.

Под интегрированными тестами я подразумеваю юнит-тесты, прохождение или падение которых зависит более чем от одной единицы нетривиального поведения. Очень часто в индустрии мы вместо быстрых и изолированных юнит-тестов пишем тесты, которые запускают на исполнение большие объемы кода или общаются с базой данных через ActiveRecord.

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

Обеспечить непрерывное повышение качества системы с помощью быстрых изолированных юнит-тестов можно только с помощью дисциплины Test Driven Development или написания тестов до кода (Test First). Это утверждение можно проверить, выбрав не покрытую тестами часть системы, которая выглядит качественно, и попробовав зафиксировать её поведение с помощью изолированных тестов. Степень легкости процесса будет соответствовать степени тестопригодности системы.

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

Интеграционное тестирование
,
Юнит-тестирование

Другие доклады секции Тестирование, A/B-тестирование