Здравствуйте, Sharov, Вы писали:

S>Это что за зверь такой, на каком уровне он работает? На уровне api? Где про это почитать?

Да, это такой мок, но уже для целого внешнего приложения. Взаимодействие — через API. Точно так же, как с реальной системой. Обычно эмулируются внешние http-сервисы, но можно еще и всякие очереди сообщений обрабатывать. В зависимости от того, как именно у вас процесс построен, симулятор может запускаться отдельным приложением или изнутри теста (поднимать временный веб-сервис, опускать после завершения теста). Где почитать — не знаю, мы независимо это изобрели в рамках велосипедостроения .

Собственно, история. Мы первые симуляторы начали делать для проверки/тестирования нетривиальных настроек http-клиентов (у нас с десяток сервисов, использующих разные библиотеки). Если с базами данных более-менее все понятно (там соединений единицы, большинство пулов имеют какой-то разумный таймаут), то с http-клиентами беда. В них совершенно детское количество одновременных соединений (2-4 на целевой хост) по-умолчанию. В добавое еще огромные таймауты на все запросы и ожидание соединения из пула. Так что хотелось иметь возможность видеть, что оно не работает, а после изменения — работает. Поэтому на коленке были собраны простенькие симуляторы под каждое приложение. Почти все нужное (вроде асинхронных http-серверов на монадах) у нас было. Нужно было дописать только асинхронный sleep. Симуляторы были без логики, ответы — это подстановка одного-двух параметров в хардкоженый шаблон ответа. Ну и вообще работа с ними была плюс-минус ручная на первом этапе. Дописал метод, заменил вызов в маршрутизации на новый — и готово.

Следующим этапом было внедрение этих технологий в CI в новые сервисы (уже не для настройки пулов). Разработчикам было лень писать симулятор под каждый проект. Поэтому они написали один универсальный. Ему передается список URL, ответы и задержки для них. Конфигурация на отдельном порту. Поэтому в симуляторе можно вообще что угодно делать. Интеграционные тесты по необходимости конфигурируют ответы и гоняют сервис. И еще. Для CI есть обвязка, которая деплоит симулятор в кубернетес и настраивает приложение на его использование. Потом тесты деплоят приложение (с правильными лимитами) и все тестируется. Если поднимать сервер внутри тестового кода, в CI будет очень сложно передать правильный адрес (тест работает где-нибудь на worker node в совершенно другом пуле).

Эти симуляторы очень хорошо легли на нашу концепцию тестирования. У нас основные тесты — интеграционные. В коде много ручных частей, включая sql-запросы в базу и ручная же сериализация/парсинг в dto и внутренние структуры (зачем — отдельный большой разговор). И если парсинг еще можно проверить в юнит-тесте, то sql-запросы — нет. Поэтому автоматически нужна база и тесты становятся интеграционными. С эмуляторами можно проверить все уровни обработки сразу. Также можно эмулировать отказы (коды ошибок, таймауты и т.п.). Инфраструктура у нас со свободными лицензиями, поэтому можно все необходимое поднять локально. Разработчик может хоть в лесу сервис запускать и тестировать. А еще у нас build tool умеет запускать только "изменившиеся или упавшие тесты" в приложении. Поэтому в типичных сценариях разработки/отладки запускаются только релевантные сценарии. В общем, это все здорово уменьшает время обратной связи. Позволяет делать простые регрессии (можно взять реальный ответ сервера и сделать из него тестовый сценарий). Все это можно запускать на всех этапах начиная с локальной разработки и заканчивая CI. Вся эта схема еще и достаточно стабильна — тесты не падают из-за того, что что-то происходит с другой системой.

Сейчас у нас в коде идут сервис и симулятор его зависимостей. В планах переделать на "сервис и симулятор этого же сервиса". Симулятор публиковать в репозиторий. В этом случае CI может выкачивать симуляторы зависимостей и гонять тесты на них. Цель — чтобы симулятор был к коду основного приложения (он может и какую-то часть кода использовать). В этом случае при изменении API/поведения больше шансов сразу получить и обновленный симулятор. И следующий CI у пользователей уже будет тестировать код с использованием новой версии. Т.е. интеграционные ошибки будут находиться еще раньше. Но это пока мечты

Если что интересно — спрашивайте. Расскажу подробнее.