fbakiyev Автоматизация тестирования
Выбрать полезную проверку
Изучи требуемое поведение, существующие тестовые решения и известный сбой. Выбери самый низкий уровень, способный его обнаружить. Выводи ожидаемый результат из контракта, инварианта или независимого расчёта по тестовым данным, а не из той же вспомогательной функции, которую проверяешь.
Решения при реализации
- Используй контрпример, который не пройдёт при дефектном поведении. Когда это практически возможно, подтверди, что новый регрессионный тест падает до исправления и проходит после него. Тест, который лишь вызывает новый метод, может не давать сигнала регрессии.
- Изолируй состояние от порядка и параллельности запусков. Используй собственные записи или пространства имён, сбрасывай изменённые средства управления временем и случайностью, удаляй только созданное тестом состояние. Новый объект теста не сбрасывает общую базу, кеш, процесс или переменную окружения.
- Синхронизируйся по наблюдаемому условию с ограничением времени или управляемому барьеру вместо пауз в надежде на нужный момент. Для гонки явно организуй существенное чередование; для правила таймаута при необходимости используй принятый в проекте механизм управления временем.
- Подменяй ту границу, которая сохраняет предмет заявленной проверки. Сохраняй характерные сериализацию и ошибки; заглушка проверяемой транзакции или дедупликации может полностью убрать дефект из теста.
- Исследуй нестабильность до изменения повторов. Сохраняй доказательства первого сбоя и различай гонки продукта, утечки тестового состояния, нестабильные зависимости и инфраструктурные ошибки. Изолируй нестабильный тест только с понятным дальнейшим действием; не отключай его незаметно и не считай успешный повтор доказательством исправления.
- Используй широкие снимки только при намеренном и проверяемом охвате. Небольшая проверка поведения часто лучше переживает постороннее изменение оформления и делает нарушенный инвариант заметным.
Не переноси покрытие логики в E2E только потому, что браузерная инфраструктура уже существует. Делай тесты обязательными в CI только при надёжном, разумно ограниченном выполнении и в рамках запрошенного изменения конфигурации.
Результат и проверка
Верни исполняемые тесты и необходимые данные, отличимый сбой, который они покрывают, а также реально выполненные команды и наблюдаемые результаты. Проверяй порядок или параллельный запуск только при риске общего состояния; не повторяй успешные наборы тестов без новой причины.
Явно указывай недоступные зависимости и непроверенные интеграции. Изменение исходников теста не доказывает, что тест запускался. Отдельный план тестирования или документ передачи работы необязателен, если задача его не требует.