Сначала важно понять контекст. В CQRS команды изменяют состояние и возвращают лишь подтверждение или ошибку. Запросы возвращают данные, не изменяя состояние. Часто эта архитектура сопровождается Event Sourcing (хранением состояния как последовательности событий). Для тестирования это означает, что мы должны проверять: 1) Корректность изменения состояния при выполнении команды. 2) Корректность проекций (читаемых моделей), построенных на основе событий. 3) Согласованность между командной и запросной сторонами.
Уровень 1: Модульное тестирование (Unit Testing). Это основа. Для модульного тестирования команд и их обработчиков (Command Handlers) идеально подходит подход, основанный на домене. Используйте фреймворк xUnit (например, JUnit для Java, pytest для Python, NUnit для .NET). Тестируйте обработчик команды в изоляции, передавая ему фиктивные (mock) репозитории или источники событий. Проверяйте, что после выполнения команды генерируется ожидаемое событие или корректно обновляется состояние агрегата.
Пример на псевдокоде: Вы тестируете `ConfirmOrderCommandHandler`. Вы создаете агрегат `Order` в состоянии "ожидает", передаете команду `ConfirmOrderCommand` и проверяете, что было сгенерировано событие `OrderConfirmedEvent` и состояние агрегата изменилось на "подтвержден". Для мокинга используйте библиотеки с открытым кодом: Mockito (Java), unittest.mock (Python), Moq (.NET).
Уровень 2: Интеграционное тестирование. Здесь мы проверяем взаимодействие между компонентами, например, запись события в хранилище событий (Event Store) и его последующую обработку проекторами (Projectors). Используйте тестовые контейнеры (Testcontainers) — мощный инструмент с открытым кодом, который позволяет запускать реальные базы данных (PostgreSQL, MongoDB), брокеры сообщений (RabbitMQ, Kafka) в Docker-контейнерах для тестов. Это обеспечивает тестирование почти в реальной среде.
Напишите тест, который: 1) Выполняет команду через командную шину. 2) Проверяет, что событие появилось в Event Store. 3) Запускает проектор вручную или ждет его асинхронного срабатывания. 4) Проверяет, что читаемая модель (например, таблица в SQL или документ в MongoDB) обновилась в соответствии с событием. Для .NET отлично подходит xUnit с Testcontainers. Для экосистемы JS/TS можно использовать Jest вместе с testcontainers-node.
Уровень 3: Сквозное (End-to-End) тестирование. Оно проверяет полный поток: от HTTP-запроса до ответа. Для этого подходят фреймворки для тестирования API (Supertest для Node.js, RestAssured для Java, requests в связке с pytest для Python). Ваш тест должен: отправить POST-запрос для создания команды, получить ID, а затем отправить GET-запрос к конечной точке запросов, чтобы убедиться, что данные представлены корректно. Здесь важно также тестировать eventual consistency ( eventual согласованность). После отправки команды запросная модель может обновиться не мгновенно. Тесты должны уметь ожидать этого, используя поллинги или механизмы ожидания.
Уровень 4: Тестирование проекций. Это специфичный для CQRS вид тестирования. Создайте набор тестовых событий (фикстуры), воспроизведите их через проектор и проверьте итоговое состояние читаемой модели. Это можно делать как на уровне модульных тестов (с моками БД), так и на интеграционном уровне с реальной БД. Инструменты: опять же, pytest с фикстурами, JUnit с @ParameterizedTest для разных сценариев событий.
Особое внимание — тестированию саг (Saga) или процесс-менеджеров, которые координируют долгоживущие бизнес-транзакции. Их логика сложна, так как они реагируют на события. Используйте методологию "given-when-then". Given: начальное состояние саги и список уже обработанных событий. When: новое входящее событие. Then: проверьте, какие команды отправляет сага и в какое новое состояние она переходит. Библиотеки для тестирования на основе спецификаций, такие как Cucumber (открытый код), могут быть полезны для описания таких сценариев на языке, понятном бизнес-аналитикам.
Инструментарий с открытым кодом для CQRS-тестирования:
- **Eventuous** (для .NET): предоставляет встроенные тестовые хелперы для агрегатов и проекций.
- **Axon Framework** (для Java): имеет мощную тестовую инфраструктуру для тестирования агрегатов, саг и проекций.
- **Laravel Event Sourcing** (для PHP): пакет Spatie, который включает инструменты для тестирования.
- **jest** и **testcontainers-node** для экосистемы Node.js.
Тестирование CQRS-систем требует сдвига парадигмы от тестирования состояния базы данных к тестированию событий и их проекций. Но с правильным набором инструментов с открытым кодом и многоуровневой стратегией вы сможете построить надежный тестовый барьер для своей событийно-ориентированной архитектуры, обеспечивая ее стабильность и предсказуемость.
Комментарии (6)