Тестирование backend-приложений¶
Требования этого документа применяются к backend-приложениям, API,
worker-процессам, consumer-процессам и data pipelines. Уровни обязательности
определены в корневом README.md.
Общие свойства проверок, включая воспроизводимость и изоляцию данных,
регулируются DEV-VER-001–DEV-VER-007; этот документ задаёт только
backend-специфичные свойства тестов.
В этом документе:
- unit-тест проверяет одну единицу поведения в памяти процесса;
- integration-тест проверяет взаимодействие компонента с реальной инфраструктурой или другим компонентом;
- end-to-end-тест (e2e) проверяет развёрнутую систему через публичные интерфейсы;
- test double — общее название mock, stub, fake и spy.
BE-TST-006. Область unit-теста¶
Уровень: MUST
Применяется к: unit-тестам
Unit-тест должен выполняться в одном процессе и не обращаться к сети, файловой системе, реальной базе данных, broker, cache, системным часам или внешнему процессу.
Зависимость от таких ресурсов должна передаваться через явную границу и заменяться контролируемым test double.
Обоснование¶
Изолированный unit-тест быстро и точно локализует ошибку бизнес-логики.
Проверка¶
- запуск без сетевого доступа и внешней инфраструктуры;
- review зависимостей тестируемой единицы;
- контроль времени выполнения unit-набора.
Исключения¶
Чтение неизменяемого fixture-файла допускается, если парсинг файла является непосредственным предметом теста.
BE-TST-007. Сценарии unit-тестирования¶
Уровень: SHOULD
Применяется к: unit-тестам бизнес-логики и преобразований
Набору следует проверять успешный результат, граничные значения, значимые ветвь бизнес-правила и ожидаемые ошибки. Для алгоритма, зависящего от порядка, повторов или конкурентного состояния, следует иметь отдельные сценарии этих условий.
Assertions следует проверять результат и значимые побочные эффекты, а не внутреннюю последовательность вызовов реализации.
Обоснование¶
Основной риск бизнес-логики сосредоточен в границах, альтернативных ветвях и отрицательных результатах.
Проверка¶
- сопоставление тестов с таблицей решений или требованиями;
- branch coverage как вспомогательный индикатор;
- review assertions и негативных сценариев.
Исключения¶
Недостижимая защитная ветвь может не иметь отдельного unit-теста, если она проверяется статически и это обосновано в коде.
BE-TST-008. Использование test doubles в unit-тестах¶
Уровень: SHOULD
Применяется к: mock, stub, fake и spy в unit-тестах
Test double следует использовать для внешней по отношению к тестируемой единице границы. Запрещено подменять сам предмет теста, value objects и внутренние методы только для подтверждения текущей реализации.
Mock expectations должны проверять только взаимодействия, являющиеся частью контракта или значимым побочным эффектом. Избыточное число expectations должно быть заменено проверкой результата либо fake-реализацией границы.
Обоснование¶
Mock внутренней реализации делает рефакторинг ложной регрессией и позволяет тесту проходить без проверки результата.
Проверка¶
- review границ test doubles;
- пробный рефакторинг без изменения поведения;
- проверка отсутствия mock для тестируемого класса или функции.
Исключения¶
Spy внутреннего события допускается для недоступного иначе значимого наблюдаемого эффекта с явным обоснованием.
BE-TST-009. Реальная инфраструктура integration-теста¶
Уровень: MUST
Применяется к: integration-тестам базы данных, broker, cache, файлового или сетевого протокола
Integration-тест должен использовать реальный экземпляр инфраструктурного компонента той же поддерживаемой версии, что и целевая среда. Экземпляр должен создаваться автоматически и быть изолированным, например с помощью container.
Запрещено заменять in-memory реализацией поведение, зависящее от SQL dialect, транзакций, индексов, блокировок, протокола, сериализации или гарантий broker.
Обоснование¶
Упрощённый mock не воспроизводит критичные особенности реального компонента и создаёт ложноположительный результат.
Проверка¶
- review версии и способа запуска инфраструктуры;
- проверка тестов миграций, транзакций и протокола;
- запуск в чистом окружении GitLab Runner.
Исключения¶
Совместимая embedded-реализация допускается только при подтверждённом совпадении проверяемой семантики и отдельном тесте с целевым компонентом.
BE-TST-010. Подмена внешней системы в integration-тесте¶
Уровень: MUST
Применяется к: интеграции с системой вне контроля проекта
Внешняя система может заменяться управляемым mock server, stub или emulator, если test double работает на реальной транспортной границе и соблюдает зафиксированный протокол.
Ответы test double должны проверяться по OpenAPI, AsyncAPI, JSON Schema, protobuf или иному версионируемому контракту. Должны поддерживаться сценарии успеха, protocol error, timeout, недоступности и некорректного ответа, если они допустимы контрактом.
Обоснование¶
Протокольный test double обеспечивает воспроизводимость без подмены поведения API произвольной объектной заглушкой.
Проверка¶
- contract validation запросов и ответов;
- негативные integration-тесты;
- review соответствия версии test double версии внешнего контракта.
Исключения¶
Sandbox внешней системы следует использовать вместо test double, если она стабильна, изолирована, доступна в CI и позволяет воспроизводить обязательные ошибочные сценарии.
BE-TST-011. Изоляция integration-тестов¶
Уровень: MUST
Применяется к: integration-тестам с изменяемым состоянием
Каждый тест должен получать известное начальное состояние и не зависеть от результата другого теста. Очистка, rollback транзакции или уникальный namespace должны обеспечивать безопасный повторный и параллельный запуск.
Миграции целевой версии должны применяться к чистому хранилищу тем же механизмом, что и при поставке приложения.
Обоснование¶
Общее неуправляемое состояние скрывает зависимости между тестами и ошибки миграции.
Проверка¶
- запуск в случайном порядке и параллельно;
- повторный запуск после прерванного pipeline;
- развёртывание чистого хранилища только через production-механизм миграций.
Исключения¶
Последовательный сценарий допускается как один тест с несколькими явно зависимыми шагами.
BE-TST-012. Границы integration-тестирования¶
Уровень: MUST
Применяется к: точкам взаимодействия backend-компонента
Integration-тесты должны проверять сериализацию, схему данных, миграции, транзакционные границы, идемпотентность и отображение ошибок на каждой используемой границе, где соответствующее свойство применимо.
Для consumer должны проверяться повторная доставка и недопустимое сообщение. Для исходящего вызова должны проверяться timeout и отказ зависимости.
Обоснование¶
Большинство дефектов интеграции возникает на границе форматов, гарантий и частичных отказов, а не в успешном вызове.
Проверка¶
- матрица границ и сценариев;
- fault injection;
- contract-тесты и проверка схем.
Исключения¶
Сценарий может проверяться на уровне e2e вместо integration только с явной ссылкой на соответствующий e2e-тест.
BE-TST-013. Область e2e-теста¶
Уровень: MUST
Применяется к: автоматизированным e2e-тестам
E2e-тест должен взаимодействовать с развёрнутой системой только через публичные API, сообщения или пользовательские интерфейсы. Прямое изменение внутренней базы или вызов внутреннего метода для выполнения проверяемого действия запрещены.
Setup и cleanup могут использовать отдельный контролируемый тестовый интерфейс, если он недоступен в production и не изменяет сам предмет проверки.
Обоснование¶
E2e-тест подтверждает пользовательский контракт и совместную работу компонентов, а не внутреннюю реализацию одного сервиса.
Проверка¶
- review используемых endpoints и credentials;
- сетевой контроль обращений теста;
- проверка недоступности setup-интерфейса в production.
Исключения¶
Не допускаются для выполнения проверяемого действия. Побочный эффект, не наблюдаемый через публичный контракт, должен проверяться integration-тестом владеющего компонента.
BE-TST-014. Минимальный критичный e2e-набор¶
Уровень: SHOULD
Применяется к: e2e-стратегии проекта
E2e-набору следует покрывать критичные пользовательские сценарии, межсервисные контракты и сквозные security-границы. Он должен оставаться минимальным; варианты бизнес-правил и граничные значения должны преимущественно проверяться на unit- и integration-уровнях.
Для сценария должны быть определены предусловия, критерий успеха и диагностические артефакты при отказе; отдельный владелец на каждый тест не требуется.
Обоснование¶
Небольшой e2e-набор даёт сквозную уверенность без медленного и нестабильного дублирования нижних уровней.
Проверка¶
- сопоставление сценариев с критичными потоками системы;
- поиск дублирования с тестами нижних уровней;
- контроль длительности и стабильности набора.
Исключения¶
Дополнительный полный e2e-набор может выполняться по расписанию или перед релизом.
BE-TST-015. Среда e2e-тестирования¶
Уровень: MUST
Применяется к: запуску e2e-тестов
Среда должна развёртываться автоматически из проверяемых артефактов одного Git commit и использовать версии зависимостей, совместимые с целевой средой. Конфигурация, feature flags и тестовые замены внешних систем должны фиксироваться в отчёте запуска.
Собственные сервисы проверяемого потока не должны заменяться mock. Внешняя система вне контроля проекта может заменяться contract-validated sandbox, emulator или mock server.
Обоснование¶
Смешение версий и скрытых замен делает результат e2e неприменимым к поставляемой системе.
Проверка¶
- сопоставление commit SHA и версий images;
- review deployment manifest и отчёта;
- проверка списка реальных и заменённых зависимостей.
Исключения¶
Проверка обратной совместимости может намеренно использовать несколько версий, если матрица версий является предметом теста.