DDD-спецификация: гайд для тестировщика

Тестирование DDD: матрицы переходов, BR-тесты, E2E, Saga.

DDD тестирование — этот документ собирает все блоки тестирования из DDD-спецификации и реорганизует их по типам тестов. Для каждого раздела даны конкретные чеклисты, матрицы и примеры тест-кейсов.

Связанные документы:

DDD тестирование: роль QA в DDD-спецификации

Тестировщик извлекает из каждого раздела DDD-спецификации конкретные тест-кейсы. Спецификация -- не абстрактный документ, а прямой источник: граничных значений, матриц переходов, чеклистов авторизации и сценариев ошибок. Задача QA -- превратить каждый раздел в проверяемые тесты и убедиться, что реализация соответствует контракту.

1. Границы тестирования

Источник: раздел 1 -- Bounded Context

Bounded Context определяет границы тестирования:

Что внутри -- тестируем полностью (функционально, интеграционно, нагрузочно). В примере: создание, подтверждение и отмена заказов, управление позициями, расчет стоимости.
Что снаружи -- тестируем только на уровне интеграции (контракты, таймауты, обработка ошибок). В примере: каталог товаров, обработка платежей, логистика.
Соседние контексты -- для каждого соседа три сценария: корректный обмен, недоступность, некорректные ответы и таймауты.

2. Терминология в тестах

Источник: раздел 2 -- Ubiquitous Language

Глоссарий -- основа для именования тест-кейсов и тестовых данных:

Те же термины в тестах: test_createOrder_withTwoItems_success, а не test_makePurchase_withProducts.
Проверять, что в UI, API-ответах и ошибках используются правильные термины из глоссария.
Антислова -- повод для баг-репорта: если в интерфейсе встретилось слово из колонки "Не используем" -- это дефект. Например, "Покупка" вместо "Заказ", "Продукт" вместо "Товар".

3. Тестовые данные из доменной модели

Источник: раздел 3 -- Domain Model

Доменная модель -- источник тестовых данных и граничных значений:

Типы данных -- тесты на невалидные значения: quantity = 0, amount = -0.01, zipCode = "abc".
Ограничения -- граничные значения: quantity = 1 (мин), quantity = 99 (макс), amount = 0.01.
Обязательность -- apartment необязательно: проверить, что заказ создается без квартиры.
Агрегат -- транзакционная граница: добавление позиции и пересчет суммы атомарны.

Примеры граничных значений:

Атрибут	Валидные	Невалидные	Граничные
`quantity`	5, 50	0, -1, 100, "abc"	1 (мин), 99 (макс)
`amount`	100.00, 1.00	-0.01, null	0.01 (мин допустимый)
`zipCode`	"101000"	"abc", "12345", "1234567"	6 цифр ровно

4. Матрица переходов состояний

Источник: раздел 4 -- Жизненный цикл и состояния

Диаграмма состояний -- главный источник тест-кейсов. Полная матрица переходов (6 x 6 = 36 комбинаций, 7 допустимых):

Из / В	CREATED	CONFIRMED	PAID	SHIPPED	DELIVERED	CANCELLED
CREATED	--	да	нет	нет	нет	да
CONFIRMED	нет	--	да	нет	нет	да
PAID	нет	нет	--	да	нет	нет
SHIPPED	нет	нет	нет	--	да	нет
DELIVERED	нет	нет	нет	нет	--	нет
CANCELLED	нет	нет	нет	нет	нет	--

Каждое "да" -- позитивный тест-кейс: переход выполнен, статус изменился, событие опубликовано.
Каждое "нет" -- негативный тест-кейс: система возвращает корректную ошибку, статус не меняется.
Конечные состояния: DELIVERED и CANCELLED -- из них нет выхода. Любая попытка перехода должна быть отклонена.

5. Тесты авторизации

Источник: раздел 5 -- Роли и права доступа

Матрица доступа -- прямой чеклист тестов авторизации:

Команда	Customer	Manager	Admin
`CreateOrder`	да (свой)	нет	да
`ConfirmOrder`	да (свой)	нет	да
`AddItem`	да (свой, CREATED)	нет	да
`CancelOrder`	да (свой, до оплаты)	нет	да
`ShipOrder`	нет	да	да
`DeliverOrder`	нет	да	да
`InitiateRefund`	нет	нет	да

Каждое "да" -- позитивный тест (200 OK).
Каждое "нет" -- негативный тест (403 Forbidden).
Изоляция данных: Покупатель A не видит заказы Покупателя Б.
Региональные ограничения: Менеджер "Москва" не видит заказы "СПб".

6. Тесты бизнес-правил

Источник: раздел 6 -- Бизнес-правила и инварианты

Каждый BR-N -- минимум два теста:

BR	Позитивный тест	Негативный тест	Граничный тест
`BR-1`	Заказ с 1 позицией -> OK	Заказ с 0 позиций -> ошибка	1 позиция (граница)
`BR-2`	quantity = 5 -> OK	quantity = 0 -> ошибка, quantity = 100 -> ошибка	quantity = 1 (мин), quantity = 99 (макс)
`BR-3`	totalAmount = 1.00 -> OK	totalAmount = 0.99 -> ошибка	1.00 (граница)
`BR-4`	Отмена в CREATED -> OK	Отмена в PAID -> ошибка	Отмена в CONFIRMED (последний допустимый)
`BR-5`	Тот же товар -> количество увеличивается	--	Увеличение до quantity > 99
`BR-6`	addItem в CREATED -> OK	addItem в CONFIRMED -> ошибка	--

7. Тесты команд

Источник: раздел 7 -- Commands

Каждая команда порождает набор тест-кейсов:

Happy path -- все валидно, команда выполнена, событие опубликовано, статус изменился.
Невалидные параметры -- каждый параметр: пустой, null, за пределами допустимого диапазона.
Неправильный статус -- например, AddItem для заказа в PAID -> ошибка ORDER_MODIFICATION_FORBIDDEN.
Неправильная роль -- например, Менеджер вызывает CreateOrder -> 403 Forbidden.
Проверки BR -- каждое указанное бизнес-правило отдельным тестом.
Событие -- payload содержит корректные данные после успешного выполнения.

8. Тесты событий

Источник: раздел 8 -- Domain Events

Для каждого события проверять:

Факт публикации -- после команды событие опубликовано в outbox / Kafka.
Payload -- все поля корректны, типы данных соответствуют спецификации.
Подписчики получают -- каждый указанный подписчик обработал событие.
Идемпотентность -- повторная обработка не дублирует эффект (склад не резервирует дважды).
Порядок -- OrderCreated приходит раньше OrderPaid.

9. Тесты read-модели

Источник: раздел 9 -- Queries

Тесты на read-модель:

Фильтры -- каждый фильтр работает корректно (status, customerId, dateFrom/dateTo), комбинации фильтров.
Пагинация -- первая страница, последняя, пустая, выход за границы (page > max).
Сортировка -- по умолчанию (дата создания) и явная (по сумме), ASC/DESC.
Изоляция данных -- Покупатель A не видит заказы Покупателя Б через SearchOrders.
Консистентность -- после CreateOrder заказ сразу появляется в SearchOrders.

10. Контракт-тесты API

Источник: раздел 9.1 -- API-контракт (OpenAPI)

API-контракт -- основа для контракт-тестов:

Schema validation -- каждый эндпоинт: ответ соответствует OpenAPI spec.
Все HTTP-статусы -- для каждого эндпоинта протестировать: 200/201, 400, 401, 403, 404, 409, 422, 503.
Backward compatibility -- новая версия API не ломает существующих потребителей.

Маппинг эндпоинтов для проверки:

Эндпоинт	Команда / Запрос
`POST /api/v1/orders`	`CreateOrder`
`PUT /api/v1/orders/{orderId}/confirm`	`ConfirmOrder`
`POST /api/v1/orders/{orderId}/items`	`AddItem`
`PUT /api/v1/orders/{orderId}/cancel`	`CancelOrder`
`PUT /api/v1/orders/{orderId}/ship`	`ShipOrder`
`PUT /api/v1/orders/{orderId}/deliver`	`DeliverOrder`
`POST /api/v1/orders/{orderId}/refund`	`InitiateRefund`
`GET /api/v1/orders/{orderId}`	`GetOrder`
`GET /api/v1/orders`	`SearchOrders`

11. E2E тесты из Use Cases

Источник: раздел 10 -- Use Cases

Use Cases -- сценарии для E2E-тестов:

Основной поток -> один E2E-тест "happy path" (создание заказа от авторизации до подтверждения).
Каждый альтернативный поток -> отдельный E2E-тест (например, пустая корзина, товар закончился).
Предусловия -> фикстуры: "покупатель авторизован, в корзине товары".
Постусловия -> assert-ы: "заказ в статусе CREATED, событие опубликовано".

12. UI-тесты

Источник: раздел 11 -- UI-спецификация

UI-спецификация -- источник UI-тестов:

Привязка к данным -> экран загружает данные из правильных запросов.
Привязка к действиям -> кнопки вызывают правильные команды.
Отображение ошибок -> каждая ошибка из колонки "Ошибки" отображается на нужном экране.
Платформа -> если указано "web, mobile" -- тестировать на обеих платформах.

Реестр экранов для тестирования:

ID	Название	Команды	Ошибки	Платформа
`UI-001`	Оформление заказа	`CreateOrder`, `AddItem`	`ORDER_EMPTY`, `ORDER_ITEM_OUT_OF_STOCK`	web, mobile
`UI-002`	Подтверждение заказа	`ConfirmOrder`, `CancelOrder`	`ORDER_CANCEL_FORBIDDEN`	web, mobile
`UI-003`	Список заказов	--	--	web, mobile
`UI-004`	Карточка заказа	`CancelOrder`, `InitiateRefund`	`ORDER_CANCEL_FORBIDDEN`, `ORDER_MODIFICATION_FORBIDDEN`	web, mobile
`UI-005`	Панель менеджера	`ShipOrder`, `DeliverOrder`	--	web

13. Тесты Saga

Источник: раздел 12 -- Сложные процессы (Saga / Process Manager)

Для каждой Saga (Обработка заказа, Возврат средств) пять типов тестов:

Happy path -- все шаги успешны, процесс завершен корректно.
Ошибка на каждом шаге -- отдельный тест на сбой каждого шага (резервирование, оплата, доставка).
Компенсация -- при ошибке оплаты проверить, что резерв на складе отменен.
Таймаут -- имитировать таймаут (30 сек на резерв/оплату, 5 мин на доставку), проверить retry (до 3 раз) и компенсацию.
Идемпотентность -- retry не дублирует эффект (двойной резерв, двойная оплата).

14. Негативное тестирование

Источник: раздел 13 -- Каталог ошибок

Каталог ошибок -- чеклист для негативного тестирования. Для каждой строки:

Воспроизвести условие ошибки.
Проверить код ошибки (не generic 500).
Проверить HTTP-статус.
Проверить текст сообщения.
Убедиться, что при ошибке состояние не изменилось.
Проверить отображение на нужном экране (колонка "Ошибки" в реестре экранов).

Каталог ошибок:

Код	HTTP	Когда
`ORDER_EMPTY`	422	Нарушение BR-1
`ORDER_ITEM_INVALID_QUANTITY`	422	Нарушение BR-2
`ORDER_TOTAL_TOO_LOW`	422	Нарушение BR-3
`ORDER_CANCEL_FORBIDDEN`	409	Нарушение BR-4
`ORDER_MODIFICATION_FORBIDDEN`	409	Нарушение BR-6
`ORDER_ITEM_OUT_OF_STOCK`	409	Товар недоступен
`ORDER_NOT_FOUND`	404	Несуществующий или чужой orderId
`CATALOG_SERVICE_UNAVAILABLE`	503	Сервис каталога не отвечает
`PAYMENT_SERVICE_UNAVAILABLE`	503	Платежный шлюз не отвечает
`WAREHOUSE_SERVICE_UNAVAILABLE`	503	Сервис склада не отвечает

15. Интеграционные тесты

Источник: раздел 14 -- Интеграции (Context Mapping)

Для каждой интеграции -- 4 сценария:

Нормальная работа -- корректный ответ в срок.
Недоступность -- проверить fallback (кэш, retry, circuit breaker).
Некорректный ответ -- ACL-адаптер должен обработать невалидные данные.
Таймаут -- ответ позже SLA (300ms для Каталога, 5 сек для Доставки).

Дополнительно: контракт-тесты (Pact / Spring Cloud Contract) и SLA-тесты.

16. Приемочные тесты

Источник: раздел 15 -- Критерии приемки (Acceptance Criteria)

AC -- минимальный набор тестов. Given-When-Then формат напрямую транслируется в автотесты:

AC	Given	When	Then
AC-1	Покупатель авторизован, 3 товара в корзине	Оформляет заказ	Статус CREATED, виден в SearchOrders, событие OrderCreated
AC-2	Покупатель авторизован, корзина пуста	Оформляет заказ	Ошибка ORDER_EMPTY
AC-3	Заказ в CREATED	Отменяет заказ	Статус CANCELLED, событие OrderCancelled, резерв снят
AC-4	Заказ в PAID	Пытается отменить	Ошибка ORDER_CANCEL_FORBIDDEN, статус не изменился
AC-5	Заказ в CONFIRMED	Пытается добавить товар	Ошибка ORDER_MODIFICATION_FORBIDDEN
AC-6	Менеджер, заказ в PAID	Отправляет заказ	Статус SHIPPED, событие OrderShipped
AC-7	Администратор, заказ в PAID	Инициирует возврат	Событие RefundInitiated, запуск Saga возврата
AC-8	Покупатель A, существуют заказы Покупателя Б	SearchOrders / GetOrder чужого	Чужие заказы не видны, ORDER_NOT_FOUND (404)

Тестировщик дополняет AC на основе: матрицы переходов (раздел 4), бизнес-правил (раздел 6), каталога ошибок (раздел 13), матрицы доступа (раздел 5), Saga (раздел 12).

17. Нагрузочные и security тесты

Источник: раздел 16 -- Нефункциональные требования

НФТ определяют нагрузочные, стресс- и security-тесты:

Производительность: Gatling/JMeter -- API <= 200ms при p95, 50 rps на оформление заказа, 500 rps на просмотр каталога.
Масштабируемость: стресс-тест x5 нагрузки (имитация распродаж).
Доступность: при падении одного инстанса система продолжает работать (kill pod, проверить recovery).
Безопасность: тесты аутентификации/авторизации, проверка JWT, CORS, PCI DSS compliance.

Каждая цифра из НФТ -- порог для автоматического теста. Если p95 > 200ms -- тест красный.

← Предыдущая

Гайд для разработчика

Гайд для DevOps