Когда я начинал в IRP Team, то моей задачей на испытательный срок было создание инструмента для мокирования (имитации поведения) внешних веб-сервисов. Команде был нужен этот инструмент для покрытия автотестами операций с порталами электронных документов.

Поскольку задача мне ставилась для целей тестирования, то я не создавал совсем новый "велосипед" и функционал поместил в расширении для юнит-тестирования. Оглядываясь назад, это уже не кажется красивым решением, так как юниты запускаются отдельно и независимо от интеграционных тестов на базе Vanessa-Automation (для которых моки и создавались). Хотя возможно "Units" давно пора немного расширить и переименовать в "Testing"? Или даже забрать в ядро? 🤔

Сейчас у меня в работе задачка по доработке одного расширения для IRP, в котором работу с физическим фискальным аппаратом нужно заменить на интеграцию с одним веб-сервисом. Проблема в том, что разработку я делаю у себя, а тестирование можно делать только на специальном ноутбуке, который мне по запросу включают - только там есть доступ к веб-сервису. Усложняет задачу то, что тут помимо смены реализации API, из расширения нужно изменить также внешнее поведение системы - т.е. мне нужно раз за разом смотреть что вообще происходит и как изменяется поведение рабочего места кассира (расширения уж очень капризные), но каждый раз я попадал на таймауты к недоступному сервису.

Короче очень захотелось поднять заглушки, чтобы получать фейковые ответы... И тут я вспоминаю, что мокирование в продукте уже есть и что это же я сам его разработал для похожих целей 🤦‍♂️

Механизм моков после сегодняшнего явно ожидает еще одна итерация доработки, так как не ожидалось их ручное оформление. Была концепция, что у базы во время настройки есть доступ к нужному сервису и можно буквально "записывать" ответы, на базе которых будут созданы сценарии для тестов. К счастью, даже текущего функционала оказалось достаточно и не пришлось ничего дорабатывать.

Небольшая автоматизация и работа полетела!

#понедельник #тестирование #мокирование