Как тестировать: полное руководство по CQRS с открытым кодом

Архитектура CQRS (Command Query Responsibility Segregation) кардинально меняет подход к проектированию приложений, разделяя модели для записи (команды) и чтения (запросы). Это приносит огромные преимущества в производительности и масштабируемости, но значительно усложняет процесс тестирования. Как же обеспечить надежность такой системы? Данное руководство проведет вас через все уровни тестирования CQRS-приложения, используя популярные инструменты с открытым исходным кодом.

Первое и главное правило: тестируйте команды и запросы изолированно. Модель команд (Write Model) и модель запросов (Read Model) живут отдельно и синхронизируются асинхронно через события. Поэтому их тестирование должно быть независимым. Для тестирования команд начните с модульных тестов. Здесь ваша цель — проверить бизнес-логику в агрегатах и доменных сервисах. Используйте простой фреймворк вроде JUnit (Java) или pytest (Python). Убедитесь, что команда при валидных данных создает корректное событие домена (Domain Event), а при невалидных — выбрасывает исключение.

Следующий уровень — интеграционные тесты для команд. Они проверяют, как команда взаимодействует с инфраструктурой: репозиторием, шиной событий, внешними сервисами. Здесь незаменим Testcontainers — инструмент, который запускает реальные базы данных (PostgreSQL, MongoDB) или брокеры сообщений (RabbitMQ) в Docker-контейнерах для тестов. Вы можете написать тест, который отправляет команду `CreateUserCommand` через командный обработчик, проверяет, что пользователь сохранен в БД, и что событие `UserCreatedEvent` опубликовано в шину.

Тестирование модели запросов (Read Model) имеет свою специфику. Поскольку это, как правило, денормализованные проекции (например, таблицы в SQL или документы в NoSQL), их тестирование часто сводится к проверке корректности обновления. Используйте подход, основанный на событиях. Напишите тест, который: 1) берет серию событий из истории (например, `UserCreated`, `UserEmailUpdated`), 2) передает их обработчику проекции (Projection Handler), 3) проверяет, что итоговое состояние проекции в БД соответствует ожидаемому. Для этого также отлично подходит Testcontainers.

Самый сложный и важный вид тестирования в CQRS — сквозное (End-to-End, E2E) тестирование всего потока: команда -> событие -> обновление проекции -> запрос. Здесь нужно имитировать полный цикл. Алгоритм E2E-теста: 1) Отправить команду через HTTP API (используя, например, RestAssured). 2) Дождаться, пока обработчик событий обновит проекцию. Это может потребовать механизма опроса (polling) или использования заглушки для шины событий. 3) Выполнить запрос через отдельный endpoint и проверить результат. Инструменты: для API-тестов — Postman/Newman или RestAssured, для управления зависимостями — Docker Compose, чтобы поднять всё приложение в тестовом окружении.

Особое внимание уделите тестированию eventual consistency ( eventual согласованности). В CQRS запись и чтение не синхронны. Ваш E2E-тест должен учитывать эту задержку. Не пишите жесткие ожидания (`Thread.sleep`), используйте умные ожидания (awaitility-библиотека), которые периодически опрашивают систему, пока условие не выполнится или не истечет таймаут.

Рассмотрим стек open-source инструментов для Java-стека (аналоги есть для других языков). Модульные тесты: JUnit 5, AssertJ для удобных утверждений, Mockito для моков. Интеграционные тесты: Testcontainers, Spring Boot Test (если используется Spring). E2E тесты: RestAssured для HTTP, Awaitility для ожидания, Docker Compose для оркестрации. Для визуализации и управления тестовыми данными можно использовать H2 для in-memory тестов, но для интеграционных предпочтительнее реальные СУБД в контейнерах.

Пример тестового класса для команды на псевдокоде:
```
@Test
void createUserCommand_Success() {
 // 1. Arrange: подготовка команды
 var command = new CreateUserCommand("john@doe.com", "John");
 // 2. Act: выполнение через обработчик
 var events = commandHandler.handle(command);
 // 3. Assert: проверка, что создано одно событие UserCreated с правильными данными
 assertThat(events).hasSize(1).first().isInstanceOf(UserCreated.class);
}
```

Тестирование CQRS требует больше усилий на этапе настройки инфраструктуры, но оно окупается стабильностью сложной асинхронной системы. Ключ к успеху — четкое разделение типов тестов и использование современных инструментов, которые позволяют работать с реальными компонентами, а не их муляжами. Начните с модульных тестов для самой ценной бизнес-логики в командах, затем добавьте интеграционные тесты для проекций и завершите полным E2E-сценарием для критически важных пользовательских потоков.