tgoop.com/emacsway_log/1506
Last Update:
Как я делаю fitness-functions для микросервисов. Продолжение. Начало здесь.
По хуку before_scenario() (или before_tag()) создается дамп изначального состояния БД (если он не был создан ранее) утилитой pg_dump в многопоточном режиме, с использованием аргументов:
--jobs=n, где n - количество ядер процессора, len(os.sched_getaffinity(0));
--format=directory (требуется для параллельного дампа);
--clean;
Composition Pattern отлично подошел для создания дампов баз данных нескольких микросервисов.
При необходимости, созданная директория с дампом архивируется и сохраняется в хранилище (тут есть разные варианты сохранения дампов между запусками тестов, от монтирования удаленной директории до отправки архива в S3).
По хуку after_scenario() (или after_tag()) дамп изначального состояния БД восстанавливается утилитой pg_restore так же в многопоточном режиме, с использованием аргументов:
--jobs=n
--clean
Некоторые коллеги из других компаний восстанавливают БД на уровне файлов PGDATA тестируемого сервиса. Работает быстрее, но менее универсально.
При исполенении шага "Given SUT with 10000000 objects" проверяется наличие актуального предзаполненного дампа БД для указанного объема данных и производится или его восстановление, или его создание путем генерации фэйковых данных. С целью сокращения времени генерации, я генерирую данные непосредственно в БД, хотя можно и через Public API сервиса. Для генерации используется собственный performance framework, позволяющий воспроизвести селективность индексов целевой системы. Коробочные решения мне неизвестны, но за основу можно взять:
- https://hypothesis.readthedocs.io/en/latest/strategies.html
- https://github.com/litestar-org/polyfactory
На следующем шаге создаем нагрузку. Я использую тот же собственный performance framework, который автоматически определяет создавать ли зависимый объект или реиспользовать ранее созданный в соответствии с заданной вероятностной распределенностью. Коробочные решения мне опять же неизвестны, но за основу можно взять:
- https://schemathesis.readthedocs.io/
Если используется JS (например, при использовании K6), то имеет смысл обратить внимание на:
- https://dredd.org/
Для изоляции сервиса можно использовать Mountebank, WireMock или Mockintosh (на Python), pytest-httpserver. На PyPi достаточно много реализаций mock-серверов. Вплоть до стандартного http.server. Некоторые из них позволяют генерировать данные на основе OpenAPI спецификации. На JS имеет смысл посмотреть в сторону Prism, openapi-sampler. См. так же OpenAPI Generator (docs), Swagger Codegen (HOWTO).
Для относительно небольших систем нагрузочный движок можно не использовать вообще, ограничившись простой многопоточностью multiprocessing.Pool.map().
В некоторых случаях подойдет минималистичный нагрузочный движок molotov.
Для крупных систем потребуется распределенный нагрузочный движок. Locust можно запускать как библиотеку (пример). О том, как подружить Locust и asyncio, см. здесь. K6, Gatling, JMeter можно запускать через субпроцессинг.
Результат каждого запроса записывается в Graphite или в Prometheus для детализированного анализа.
Используя Gherkin, удалось совместить хранение спецификаций как функциональных, так и нефункциональных требований. При этом функциональные требования в Gherkin формате очень хорошо ложатся на EventStorming диаграмму.
[UPDATE]: см. также:
- https://allurereport.org/docs/behave/
- https://allurereport.org/docs/pytestbdd/
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1506