Используйте тесты как подтверждения

Начните с требования

Тесты подтверждают конкретные утверждения. Успешный запуск тестов не доказывает все свойства ПО. До запроса тестов определите важное поведение и дефект, который должна обнаруживать каждая проверка.

Для вымышленного экспорта организации главное требование — изоляция данных. Пользователь организации A не должен получать записи организации B. Тест только на успешное скачивание не подтверждает это требование.

Попросите агента объяснить связь между требованием и проверяемым условием. Так легче обнаружить пропущенные случаи до разрастания набора тестов.

Выберите подходящий уровень проверки

Unit-тест быстро проверяет небольшое преобразование. Интеграционный тест проверяет взаимодействие компонентов. End-to-end тест проверяет важную последовательность действий пользователя в развёрнутом приложении или его репрезентативном окружении.

Используйте самый узкий охват, который даёт нужное подтверждение. Форматтеру не нужен полный браузерный тест для каждого ввода. Для границы авторизации могут потребоваться реальный маршрут и путь доступа к данным. Для важного взаимодействия в браузере нужны подтверждения работы отрисованного интерфейса.

Нет фиксированного процентного соотношения типов тестов, подходящего для всех систем. Выбирайте по сбою, который нужно обнаружить, и стоимости сопровождения проверки.

Не допускайте общего неверного предположения

Агент может написать реализацию и тесты на основе одного недопонимания. Они будут согласованы, но требование останется невыполненным.

Допустим, реализация фильтрует записи по ID организации из запроса. Тест использует одинаковый ID для вошедшего пользователя и запроса. Он проходит. Пропущен случай, когда пользователь запрашивает ID другой организации.

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

Убедитесь, что тест способен не пройти

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

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

Для более широких изменений мутационное тестирование помогает оценить, вызывают ли выбранные изменения кода неуспешные тесты. У него есть стоимость, и оно не заменяет review требований. Применяйте его там, где дополнительные подтверждения помогают принять существенное решение.

Связывайте подтверждения с изменением

Запускайте нужные проверки на итоговой ревизии. Записывайте пропущенные проверки и причины пропуска. Результат предыдущего коммита может перестать относиться к коду после исправления по review.

Делайте тесты понятными. Явная подготовка и проверяемое условие лучше большого вспомогательного метода, который скрывает важное условие. Удаляйте избыточные проверки, если они увеличивают стоимость сопровождения и не обнаруживают другой сбой.

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