Как автотестируем систему батчинга заказов ч.1
Это продолжение предыдущего поста.

У нас в проекте написаны интеграционные тесты, которые тестируют нашу систему в интеграции - мы поднимаем БД в Docker, запускаем тестовый хост SUT (System Under Test) и запускается Kafka с помощью TestContainers. Но мы не только публикуем события в Kafka но и еще потребялем их. Поднимается отдельный хост с консьюмерами. И тесты проверяют опубликованные события. Ну и 25 фейков внешних зависимостей. В общем-то и все.

В тестах мы сетапим данные, выполняем действий, проверяем результаты. Часть тестов написана на голом nUnit, а часть с помощью LightBDD (из названия следует, что это обертка для описания шагов в тесте в BDD стиле).

Эти тесты проверяют функционал самой кассы доставки: работа с чеками, курьерами, движение заказов, применение группировок.
В общем мы подумали, что наилучшим решением будет писать такие тесты рядом с этими интеграционными тестами, на уже готовой инфраструктуре. НО если все существующие тесты тестировали всю систему в изоляции (кроме перечисленных зависимостей), то у нас появляется внешняя зависимость в виде самого группировщика, который хостится в DataBricks. На самом деле на отдельном эндпоинте хостится Решала (Solver) - который говорит как объединить заказы на основе переданных данных, а логика создания и применения групп на основе его ответов лежит в нашей системе, но для простоты буду называть его группировщик. Мы явно решили ходить из нашей системы во внешнюю потому что целью наших тестов было проверить как группировщик объединит заказы в поездку при определенных условиях.
Вот мы задаем заказы, время их принятия, курьеров, вызываем группировщик - получаем группы и проверяем что группы применились.
Напомню количество переменных которые влияют на группировку:
1. Заказы:
a. Статус;
b. Время от принятия
c. Прогнозное время до конца готовки;
2. Курьеры:
a. Статус;
b. Прогнозное время возращения;
3. Текущая нагрузка на пиццерию;
4. Прогноз спроса в пиццерии;
5. Маршруты:
a. Координаты заказов;
b. Чистое время в пути от Яндекса;
c. Время на сборку заказа (зависит от текущей нагрузки и кол-ва коробок в заказе);
d. Время дойти от пиццерии до машины (у каждой пиццерии разное);
e. Время дойти от каждого заказа до клиента (у каждого заказа разное);
f. Время дойти от машины до пиццерии (у каждой пиццерии разное).

Сначала я написал тесты основываясь на требованиях, а требования для такой системы у нас - двухстраничный документ. Я считаю должно быть минимум 3. 😏
Потом в процессе написания тестов решили, что стоит и дописывать кейсы с реальной пиццерии. Например заметили или пожаловались на кринж группу, мы воспроизводим такой кейс, чтобы убедиться, что проблема действительно ушла.
Таким образом написали 60+ тестов.
И тут начинается самое интересное.
Я в предыдущем посте писал, что у нас было 3 группировщика, которые группировали по разному, поэтому мы подошли к этапу, когда часть тестов не проходила на одном группировщике, часть тестов не проходила на другом группировщике. Как-то мы дошли до того, что у нас был только один группировщик, но сейчас их снова два и у них есть разные версии которые могут работать одновременно на разных пиццериях, плюс у обоих группировщиков есть разная конфигруация работы автоназначения.