TDD и практики тестирования

Цикл разработки через тесты и структура теста

TDD (test-driven development, разработка через тесты) - цикл из трёх шагов. Красный: пишешь падающий тест на ещё не написанное поведение. Зелёный: пишешь минимальный код, чтобы тест прошёл. Рефакторинг: приводишь код в порядок, а тесты держат тебя от поломки.

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

// Любой тест удобно строить в три части: подготовка данных, действие, проверка. Одно действие на тест. Название пишут по-человечески: «возвращает ошибку при отрицательной сумме» вместо «тест1». Когда такой тест падает в отчёте, причина понятна без чтения кода.

цикл красный-зелёный-рефакторинг

падающий тест, минимальный код, наведение порядка

подготовка-действие-проверка

три части теста, одно действие на тест

Поведение против реализации

Хрупкий тест получается, когда проверяют внутреннее устройство: какие методы в каком порядке позвались, какие поля стали какими. Переписал реализацию, поведение сохранил - тест всё равно красный. Такие тесты со временем начинают мешать рефакторингу, и их отключают, а не чинят.

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

// Отсюда мера: проверка вызовов уместна там, где вызов и есть результат работы - письмо отправлено, сообщение опубликовано, деньги списаны. Проверять, что сервис позвал у себя три внутренних метода, смысла нет: это и есть проверка реализации.

хрупкий тест

падает от изменения устройства, хотя поведение прежнее

Покрытие и нестабильные тесты

Покрытие показывает, какие строки исполнялись во время прогона. Это метрика ИСПОЛНЕНИЯ, а не проверки: тест, который дёргает метод и ничего не проверяет, даёт стопроцентное покрытие и нулевую пользу. Поэтому целью её не делают - её используют, чтобы найти непокрытые куски и решить, важны ли они.

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

// Правильная реакция - вынести такой тест из основного прогона и завести на него задачу, а не перезапускать. И помнить, что гонка в тесте нередко означает гонку в самом коде: у меня в замерах гонки проявлялись через раз - один прогон из трёх выдавал правильный результат при полностью сломанной синхронизации.

покрытие

какие строки исполнялись, а не что было проверено

нестабильный тест

падает через раз без изменений кода, приучает игнорировать прогон

Как отвечать: «Гонитесь ли вы за стопроцентным покрытием?»

Нет, потому что покрытие меряет исполнение строк, а не проверку поведения. Тест, который просто вызывает метод и ничего не утверждает, даёт стопроцентное покрытие и нулевую пользу - под такую метрику легко подогнать отчёт, не улучшив ничего. Я использую покрытие как подсказку: смотрю, какие куски не покрыты, и решаю по каждому, важен он или нет. Обработка ошибок, граничные случаи и денежная логика должны быть покрыты обязательно; на геттерах и на классах с одними данными настаивать бессмысленно. Куда полезнее следить за другими вещами: падает ли сборка при провале теста, нет ли нестабильных тестов, проверяют ли тесты поведение, а не устройство. Разумный ориентир - высокое покрытие критичных модулей вместо единого числа по всему проекту.

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

На чём валят

• −Делать покрытие целью. Оно меряет исполнение строк: тест без единой проверки даёт сто процентов.
• −Проверять порядок внутренних вызовов. Такой тест краснеет от рефакторинга и не ловит поломок поведения.
• −Перезапускать прогон, когда тест падает через раз. Настоящее падение утонет в привычном шуме.
• −Ждать фиксированной паузой в тестах на многопоточность. На загруженной машине пауза не спасёт, а прогон замедлится.
• −Проверять несколько действий в одном тесте. При падении непонятно, какое из них сломалось.