В мире синхронных REST API тестирование сводится к простой формуле: отправил запрос — получил ответ — проверил код состояния. Но в событийно-управляемой архитектуре (EDA) этот подход разбивается о реальность. Здесь нет прямого ответа. Событие улетает в брокер, обрабатывается асинхронно, изменяет чьё-то состояние и порождает новые события. Как убедиться, что система работает правильно, если результат её работы растянут во времени?

К счастью, микросервисная архитектура обладает высокой модульностью. Если синхронные монолиты требовали развёртывания «полотна» зависимостей для одного теста, то событийные микросервисы позволяют изолировать логику. В этой главе мы разберём многоуровневую стратегию тестирования EDA: от чистых функций до полноценных клонированных кластеров.

Это пятнадцатая глава цикла. Она опирается на главу III (schema testing, совместимость), главу V (TopologyTestDriver, state stores), главу VI (watermarks, event time), главу VII (state store testing, Changelog), главу VIII (тестирование компенсаций), главу X (BPC), главу XI (MiniCluster, TestHarness), главу XII (EmbeddedKafka), главу XIII (contract testing) и главу XIV (testing infrastructure). Здесь мы замыкаем цикл: от паттернов и архитектуры — к качеству.

IПирамида тестирования EDA

Классическая пирамида тестирования (unit → integration → E2E) в EDA имеет свою специфику. Ключевое отличие — contract testing становится отдельным слоем, параллельным пирамиде.

IIУровень 1: функции и топологии

Событийно-управляемая топология — это конвейер функций: filter, map, aggregate, join. Первый шаг — протестировать эти функции изолированно.

TopologyTestDriver: тестирование топологии в памяти

Что если ошибка не в функции map, а в том, как фреймворк маршрутизирует события между groupByKey и reduce? Писать собственный эмулятор брокера — плохая идея. Используйте встроенные драйверы.

// TopologyTestDriver для Kafka Streams
TopologyTestDriver driver = new TopologyTestDriver(topology, config);

TestInputTopic<String, OrderEvent> input = driver.createInputTopic(
    "orders",
    new StringSerializer(),
    new OrderEventSerializer());

TestOutputTopic<String, Long> output = driver.createOutputTopic(
    "customer-totals",
    new StringDeserializer(),
    new LongDeserializer());

input.pipeInput("order-1", new OrderEvent("cust-42", 150.0));

assertThat(output.readValueToMap()).containsEntry("cust-42", 1L);

driver.close();

Драйвер работает в том же JVM, эмулирует время, watermarks, repartition — без реального брокера. Работает за миллисекунды.

IIIProperty-based testing: инварианты вместо примеров

Классический unit-тест проверяет конкретные примеры: «подал X — получил Y». Property-based test проверяет инварианты: «для любых X верно Y».

// Пример property-based test на jqwik
@Property
void total_is_monotonic(@ForAll @Positive BigDecimal amount) {
    BigDecimal before = state.total();
    state.apply(new DepositEvent(amount));
    BigDecimal after = state.total();
    assertThat(after).isGreaterThanOrEqualTo(before);
}

Property-based testing ловит баги, которые никогда не придут в голову автору примеров: редкие комбинации, граничные случаи, негативные значения.

IVТестирование watermarks и event time

В главе VI мы обсуждали watermarks, late events, grace period. Как их тестировать? TopologyTestDriver позволяет продвигать event time вручную.

// Продвигаем время и проверяем закрытие окна
input.pipeInput("key-1", event1, Instant.ofEpochSecond(100));
input.pipeInput("key-1", event2, Instant.ofEpochSecond(200));

// Продвигаем watermark
driver.advanceWallClockTime(Duration.ofSeconds(300));

// Проверяем, что окно закрылось и результат появился
assertThat(output.readValueToMap()).containsEntry("key-1", 2L);

// Подаём late event ПОСЛЕ закрытия окна
input.pipeInput("key-1", lateEvent, Instant.ofEpochSecond(150));

// Проверяем, что late event обработан или отброшен согласно grace period
// ...

Что тестировать:

1. Окна закрываются правильно. Tumbling, hopping, sliding, session — каждое по своим правилам.
2. Late events попадают в grace period. Если event пришёл в пределах grace — он участвует в агрегации. Если позже — отбрасывается или уходит в side output.
3. Idle sources не блокируют watermark. Если один источник замолчал, окна продолжают закрываться по остальным.
4. Watermark propagation. Проверка, что минимум по входам работает корректно.

VТестирование stateful processors

State store — ключевой элемент stateful-обработки. Его надо тестировать отдельно:

// Проверка state store после обработки
KeyValueStore<String, Long> store = driver.getKeyValueStore("customer-totals");
assertThat(store.get("cust-42")).isEqualTo(3L);

// Проверка TTL cleanup
input.pipeInput("key-1", event1);
driver.advanceWallClockTime(Duration.ofHours(25));
driver.runScheduledPunctuators();
assertThat(store.get("key-1")).isNull();

Что тестировать:

1. State сохраняется. После обработки — в store лежат ожидаемые значения.
2. State восстанавливается. Симуляция рестарта — state загружается из changelog.
3. TTL cleanup работает. Через punctuator старые записи удаляются.
4. Дедупликация работает. Повторное событие с тем же ID — не удваивает счётчик.
5. Changelog пишется атомарно. Проверка, что события попадают в changelog в правильном порядке.

VIУровень 2: schema testing

В EDA схема — это закон. Если производитель молча изменит тип поля или удалит обязательный атрибут, потребитель упадёт. Тестирование эволюции схем должно быть встроено в CI/CD.

# В CI-пайплайне перед деплоем
- name: Validate schema compatibility
  run: |
    curl -X POST $SCHEMA_REGISTRY_URL/compatibility/subjects/orders-value/versions/latest \
         -H "Content-Type: application/vnd.schemaregistry.v1+json" \
         -d @new-schema.json
    # Если incompatible — CI fails, деплой блокируется

VIISnapshot testing схем

Дополнение к schema testing — snapshot testing:

1. Baseline. Сохранить текущую схему как baseline в git.
2. Сравнение. При изменении — сравнить новую схему с baseline.
3. Diff. Показать, что изменилось: добавлены поля, удалены, изменены типы.
4. Alert. Если breaking change — блокировать PR, требовать review.

Это простой и эффективный подход: вы явно видите, что меняется, и осознанно принимаете решение.

VIIIContract testing: API ↔ events

Когда API генерирует команды и события (глава XIII), контракт между API и event schema должен быть протестирован.

IXУровень 3: Testcontainers

Модульные тесты не проверят, как микросервис ведёт себя при сбое брокера, как происходит rebalance и как восстанавливается состояние из changelog. Для этого нужна локальная интеграционная среда.

Золотой стандарт — Testcontainers: реальный Kafka, Schema Registry, БД в Docker. Тест поднимает контейнеры, прогоняет события, проверяет итоговое состояние.

// Testcontainers + Kafka
@Container
KafkaContainer<?> kafka = new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka:7.5.0"));

@Test
void should_rebalance_and_resume() {
    // 1. Запускаем consumer 1
    // 2. Обрабатываем часть событий
    // 3. Убиваем consumer 1
    // 4. Запускаем consumer 2 — он должен подхватить партиции
    // 5. Проверяем, что все события обработаны
}

Что тестировать:

1. Rebalance. Убить consumer — проверить, что партиции перераспределены.
2. Restart. Симуляция падения — state восстанавливается из changelog.
3. Failure. Сбой брокера — consumer переподключается.
4. Deduplication. Повторная обработка — счётчик не удваивается.
5. Schema evolution. Новая схема — старые и новые события читаются.

XПроприетарные облачные брокеры

Что делать, если вы используете Kinesis, Pub/Sub или Event Hubs, у которых нет локальных open-source аналогов?

XIУровень 4: эфемерные кластеры

Когда нужно проверить производительность, нагрузку и восстановление после катастроф, локального Docker не хватит. Нужен полноценный кластер.

Эфемерные кластеры как решение

Если организация инвестирует в инфраструктуру как код (IaC), лучший подход — программное создание временного кластера под каждый крупный тест:

1. Тест запустился.
2. Кластер поднялся (Terraform, Pulumi, Kubernetes Operator).
3. Наполнился синтетикой или снэпшотом прода.
4. Прогнал тесты.
5. Кластер уничтожен.

Дорого, но это единственный способ гарантировать изоляцию и чистоту эксперимента.

XIIChaos testing: проверка на прочность

EDA — распределённая система. Она должна выживать при сбоях. Chaos testing проверяет это системно.

Что проверять:

• Убить consumer. Партиции перераспределяются, обработка продолжается.
• Убить брокер. Producer retry'ит, consumer переподключается.
• Разорвать сеть. Circuit breaker срабатывает, система не падает.
• Замедлить диск. RocksDB работает медленнее, но не падает.

XIIILoad testing: проверка под давлением

Особенность EDA: нужно генерировать миллионы событий в секунду. Не все инструменты справляются. Иногда проще написать свой генератор на Kafka Producer API, который пишет в топик с заданной скоростью.

XIVReplay testing: уникальная суперсила EDA

Reprocessing — суперсила EDA (глава VI). Как тестировать?

1. Захват. Сохранить реальные события из production в S3 или отдельный топик.
2. Replay. Проиграть эти события в staging через новую версию сервиса.
3. Сравнение. Сравнить выходы старой и новой версии. Если результаты совпадают — новая версия корректна.
4. Обнаружение. Если результаты расходятся — найти причину. Это может быть bug или намеренное изменение.

XVТестирование Saga и компенсаций

В главе VIII мы обсуждали Saga, компенсации, semantic locks. Как их тестировать?

// Temporal: тестирование компенсации
@Test
void should_compensate_when_payment_fails() {
    // 1. Запустить workflow с mock activities
    // 2. Симулировать сбой платёжного шага
    // 3. Проверить, что вызваны компенсации в обратном порядке
    // 4. Проверить, что финальное состояние консистентно
}

XVIProduction testing: безопасные эксперименты

Иногда единственный способ проверить, как микросервис поведёт себя под реальным давлением — запустить его в продакшене. Звучит страшно, но в EDA это делается безопасно:

1. Изолированные Consumer Groups. Новый микросервис подключается к продакшн-топикам со своим уникальным consumer group. Он читает данные, но не влияет на работу старых потребителей.
2. Теневые топики. Микросервис пишет результаты не в основные продакшн-топики, а в изолированные «теневые» топики, которые можно безопасно анализировать и удалять.
3. Feature flags. Включение нового поведения только для небольшого процента трафика.
4. Canary deployment. Новая версия обрабатывает 1% партиций, старая — 99%.

Это позволяет провести smoke test на реальных данных, проверить задержки и масштабирование, не рискуя сломать бизнес-процессы.

XVIICost и DX тестирования

Cost

Тестирование в EDA стоит денег:

Developer Experience

Плохой DX = тесты не пишутся. Что важно:

• Быстрый локальный запуск. Docker Compose для полного стека за 30 секунд.
• Параллелизация. Тесты должны бежать параллельно, а не последовательно.
• Понятные ошибки. Что именно упало, где, почему.
• IDE integration. Запуск тестов из IDE одной кнопкой.
• Хорошие fixtures. Готовые тестовые данные и helpers.

XVIIIЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист тестирования EDA

• Unit-тесты для всех stateless-функций (filter, map, branching)
• Property-based тесты для инвариантов (idempotency, монотонность)
• TopologyTestDriver / TestHarness для тестирования топологии
• Тесты watermarks и event time (окна закрываются правильно, late events обрабатываются)
• Тесты state store (сохранение, восстановление, TTL cleanup)
• Schema testing в CI (Backward / Forward / Full / Transitive)
• Snapshot testing схем для явного контроля изменений
• Contract testing между API и events (Pact, Spring Cloud Contract)
• Testcontainers для локальных интеграционных тестов (rebalance, restart, failure)
• Эмуляторы для проприетарных брокеров (LocalStack, Pub/Sub emulator)
• Эфемерные кластеры для E2E-тестов
• Chaos testing (Chaos Monkey, LitmusChaos, Toxiproxy)
• Load testing (k6, Gatling, Locust)
• Replay testing для проверки изменений обработки
• Тесты Saga и компенсаций
• Production testing через изолированные consumer groups и теневые топики
• Cost и DX тестирования оценены
• Быстрый локальный запуск (Docker Compose, IDE integration)

Ключевые выводы главы

1. Тестирование EDA — это спектр. Unit → Integration → Contract → E2E. Каждый уровень проверяет своё.
2. Пирамида с contract-слоем. Классическая пирамида дополняется contract testing как отдельным слоем.
3. TopologyTestDriver / TestHarness — тестирование топологии в памяти без реального брокера.
4. Property-based testing — инварианты вместо примеров. Ловит баги, которые никогда не придут в голову.
5. Тестирование watermarks — проверка event time semantics, closing windows, late events.
6. Тестирование state store — сохранение, восстановление, TTL cleanup, дедупликация.
7. Schema testing в CI — enforcement-механизм. Без него правила — надежда.
8. Snapshot testing схем — явный контроль изменений.
9. Contract testing — Pact, Spring Cloud Contract для API ↔ events.
10. Testcontainers — золотой стандарт локального интеграционного тестирования.
11. Эфемерные кластеры — единственный способ гарантировать изоляцию и чистоту эксперимента.
12. Chaos testing — проверка на прочность. Chaos Monkey, LitmusChaos, Toxiproxy.
13. Load testing — k6, Gatling, Locust. Особенность EDA — генерация миллионов событий.
14. Replay testing — уникальная суперсила EDA. Захват, replay, сравнение.
15. Тестирование Saga — happy path, компенсации, idempotency, semantic lock cleanup.
16. Production testing — изолированные consumer groups, теневые топики, feature flags, canary.
17. Cost и DX — критичны для adoption. Плохой DX = тесты не пишутся.

Глава XV цикла «Событийно-управляемая архитектура». Источники: Apache Kafka, Confluent, Apache Flink, Testcontainers, Pact, Temporal, LitmusChaos, k6, jqwik, Hypothesis, практические кейсы production-систем, FinCodeCow experience.