Определяет границы модульных тестов и практики фикстур, которые обеспечивают быстрые, детерминированные доказательства поведения домена без чрезмерного использования моков для коллабораций или превращения деталей реализации в замороженный API.
Статус пакета: справочный контекст готов для проверки человеком. Контракт и сценарии тестов завершены, но не гарантируется, что реализующая команда прошла их.
Решение
Тестировать детерминированную политику и переходы состояний через публичные интерфейсы модуля. Использовать небольшие билдера с явными релевантными значениями, реальными объектами значений, контролируемыми часами и случайностью, а фейки применять только на настоящих границах ввода-вывода.
Область применения
- Выбор тестов, границы юнита, фикстуры, билдера, двойники, время/случайность, ошибки, свойства, уверенность в мутации, именование и обратная связь CI.
- Код домена и приложения, зависимости которого можно контролировать в процессе.
- Взаимоотношения с интеграционными и контрактными тестами.
Вне этого блока
- Замена интеграционных тестов базы данных, транспорта, браузера или провайдера.
- Стремление к покрытию строк как основной цели качества.
Контракт
- Каждый тест именует одно наблюдаемое поведение, настраивает только релевантное состояние, вызывает публичную границу и утверждает стабильные выходы или состояние.
- Фикстуры по умолчанию — валидные минимальные объекты, но требуют явных значений для полей, существенных для поведения.
- Часы, идентификаторы и случайность внедряются или захватываются так, чтобы сбои воспроизводились.
- Моки проверяют протокол только там, где само взаимодействие является контрактом; в противном случае предпочтительны фейки или утверждения выходных данных.
- Тесты ошибок утверждают код домена и безопасный контекст, а не хрупкие полные сообщения, если формулировка не является публичным API.
- Исправления багов добавляют минимальный падающий тест на уровне, где дефект можно предотвратить.
Руководство по реализации
- Создавать типизированные билдера фикстур с именованными пресетами сценариев и без скрытых сетевых/базовых вызовов.
- Использовать табличные тесты для разбиения границ и тесты свойств для алгебраических инвариантов, когда это уместно.
- Периодически запускать мутационное тестирование или целенаправленное внедрение сбоев для обнаружения покрытия без утверждений.
- Держать общие фикстуры локальными для одного домена и сознательно версионировать публичные контрактные фикстуры.
Обработка сбоев и меры предосторожности
- Нестабильный модульный тест помещается в карантин только с указанием владельца и срока; его защищаемое поведение требует замещающих доказательств.
- Если тест требует обширного мокирования внутренних деталей, пересмотреть границу модуля или перенести поведение в интеграционный тест.
- Если глобальные часы или случайное зерно просачиваются между тестами, изолировать их, а не полагаться на порядок выполнения.
Верификация и эксплуатация
- Отслеживать распределение длительности, частоту сбоев, скрытые повторные ошибки, покрытие тестами изменённого кода, мутационный балл для критичных модулей и ушедшие дефекты по отсутствующим слоям тестирования.
- Поддерживать быстрый уровень предкоммита и полный уровень модульных тестов с явными бюджетами.
- Анализировать рост фикстур и дублирование настройки как сигналы дизайна.
Примеры, похожие на исполняемые, в этом пакете — это фикстуры и контракты приемки. Запустите
python tools/validate.py из корня коллекции для проверки структуры пакета и метаданных; затем
реализуйте и выполните сценарии в целевом репозитории.
Предположения при внедрении
- Имена и числовые значения в
example.yaml— это профиль внедрения, а не универсальные значения по умолчанию. - Внедряющая команда должна сопоставить акторов, классы данных, словарь ошибок и владение со своей системой.
Ссылки
- Внешний нормативный источник не требуется; этот пакет определяет решение проекта.