Ниже — сжатый, но практичный набор тестов, метрик и предложенная CI/CD-организация для уверенной поставки небольшого модуля в банковской системе.
Тесты — по уровням
- Unit tests
- Что: все критические функции бизнес-логики (валидация, расчёты процентов/комиссий, округления, проверка idempotency, сериализация/десериализация).
- Особенности: мокирование внешних зависимостей (БД, очереди, сторонние API), тесты на граничные значения, негативные сценарии, property-based для инвариантов (баланс не уходит в отрицательное при атомарной операции).
- Цель: быстрый фидбек, покрытие логики.
- Integration tests
- Что: интеграция с реальной/контейнерной БД, брокером сообщений, кешем, аутентификацией; проверки транзакционной согласованности, миграций, контрактов API.
- Особенности: использовать тестовую среду (ephemeral контейнеры), реальные SQL-запросы, rollback/cleanup.
- Включить consumer-driven contract tests (PACT) для взаимодействий с внешними сервисами.
- End-to-End (E2E)
- Что: полные сценарии пользователя/процесса: создание платежа → верификация → успешное списание/откат; сценарии отказа (сеть, 3DS, timeout).
- Особенности: запуск в staging-окружении с копией/фикшурами данных; проверка логов, метрик и исходящих событий (audit).
- Неприменимо для всех мелких кейсов — только критичные пути.
Доп. тесты (обязательно для банковской системы)
- Security tests: SAST, DAST, dependency-scan (vuln), секрет-скан; fuzzing входных данных.
- Performance/Load: p95/p99 latency, throughput для критичных операций.
- Concurrency / race-condition tests: симуляция параллельных транзакций.
- Chaos / resilience: отключение зависимостей, сетевые ошибки.
- Migration tests: forward/backward совместимость схемы данных.
Метрики покрытия и качества
- Тест-пирамида (целевое распределение): unit : integration : E2E ≈ $70\%:25\%:5\%$.
- Кодовое покрытие (целевые пороги): statement coverage $\ge 90\%$, branch coverage $\ge 85\%$.
- Mutation score (качество тестов): $\ge 70\%$.
- Точность интеграционных/контрактных тестов: успешный прогон в CI $=100\%$ для PR, иначе блокировка merge.
- Flakiness rate тестов: $<1\%$. Флаки-тесты маркировать и срочно фиксить.
- Время выполнения пайплайна на PR: целевое среднее $\le 10$ минут для quick checks (юнит/линт/скан), полные pipeline можно $\le 30$–$60$ минут для интеграции/контрактов.
- Non-functional SLA checks: p95 latency и p99 latency, error-rate 목표 (например, error-rate $\le 0.1\%$ — варьировать под бизнес).
Организация CI/CD (рекомендуемая последовательность)
- На каждый PR:
- lint + formatting
- static analysis (SAST) + dependency scan
- unit tests + coverage report
- быстрые integration/contract tests (mocked external, real DB if fast)
- если всё ок → merge в main запрещён при провале
- На merge в main:
- full build артефакта
- интеграционные тесты в ephemeral staging (контейнеры/namespace)
- consumer-driven contract verification
- security full scans (DAST)
- performance smoke tests (критичные нагрузки)
- deploy в staging (изолированная среда, production-like)
- E2E тесты в staging + observability checks (traces, metrics, audit logs)
- автоматический Canary / Blue-Green deploy в production с медленными раскрытиями и мониторингом
- автоматический rollback при превышении ошибок/latency или при критических алертах
Gate rules и автоматизация
- Блокирующие гейты: unit coverage ниже порога, failing security scans, контрактные несовпадения.
- Canary window + automated health checks (error-rate, latency, business-metrics). Если сигнал — rollback.
- Требование ручного одобрения только для high-risk deploys; для мелких фиксов — автоматический deploy при успешных проверках.
Инструменты и инфраструктура (кратко)
- Контейнеры: Docker + Kubernetes для ephemeral сред.
- CI: GitHub Actions / GitLab CI / Jenkins (pipelines as code).
- Test orchestration: Testcontainers для интеграций, Pact для контрактов.
- Security: Snyk/Dependabot + SonarQube/Checkmarx.
- Observability: Prometheus/Alertmanager + distributed tracing (Jaeger) + centralized logs.
- Feature flags + canary rollout (LaunchDarkly или встроенные).
Управление тестовыми данными и средами
- Изолированные ephemeral среды per-PR или per-merge.
- Детерминированные фикстуры + наборы данных для E2E; маскирование персональных данных.
- Стабильные seed-данные и механизмы отката миграций.
Короткие практические правила
- Всё критичное покрыть unit+integration; E2E — минимум рабочих путей.
- Автоматизировать и блокировать merge при провалах ключевых тестов.
- Метрики: покрытие, mutation, flakiness, pipeline time, deployment frequency, MTTR — отслеживать в реальном времени.
Если нужно — могу привести пример CI-пайплайна в виде конкретных шагов для вашей технологии/стека.