Платформа: обзор

В процессе разработки, возможно, вы сталкивались с ситуацией, когда необходимо изменить логику продукта и выясняется, что методы, которые нужно модифицировать, используются в нескольких местах. При этом невозможно оценить, как изменения повлияют на другие вызовы. В такой ситуации можно внести изменения, рискуя вызвать непредвиденные проблемы в неизвестном месте, или же применить консервативную стратегию — скопировать код и внести изменения только в текущий бизнес-вызов, оставив остальные вызовы без изменений. Это позволит избежать рисков, но также приведёт к усложнению системы и затруднит её поддержку. Основная проблема заключается в недостаточном покрытии тестами, что не позволяет оценить влияние изменений на систему. Если бы можно было провести полное тестирование интерфейса системы, то можно было бы смело вносить изменения и перепроверять работу кода.

Цель SmallDrillWind — выполнить задачу по проверке покрытия интерфейса, это инструмент для автоматического тестирования интерфейса, основанный на фреймворке Ruoyi. Проверка интерфейса похожа на восхождение на гору, поэтому инструмент получил название SmallDrillWind.

Общий дизайн

Цели дизайна

Общая цель SmallDrillWind состоит в том, чтобы гибко и удобно проводить тестирование покрытия интерфейса для всей системы или её части.

Основные концепции

Для достижения этой цели были выделены следующие понятия:

• Шаблоны интерфейсов: шаблоны интерфейсов содержат информацию о способе запроса, маршрутизации, формате параметров и выражении для определения успешности вызова.
• Задачи: задачи могут быть связаны с конкретными бизнес-сценариями, такими как процессы заказов. Они включают информацию о хосте, порте, конфигурации входа и других параметрах.
• Связь между задачами и шаблонами интерфейсов: эта связь определяет, какие шаблоны интерфейсов связаны с каждой задачей. Одна задача может иметь несколько шаблонов интерфейсов, а разные задачи могут использовать одни и те же шаблоны. Также поддерживается информация о зависимостях между интерфейсами и другими параметрами, такими как хост, конфигурация входа и параметры. Эта информация может быть сохранена в задачах или шаблонах интерфейсов, если она присутствует в обоих местах, то используется информация из таблицы связей.
• Конфигурация входа: предоставляет гибкий способ обработки входа через SPI (интерфейс поставщика услуг). Это позволяет настраивать процесс входа в систему. После добавления нового способа входа в исходный код, он становится доступным для использования при вызове интерфейсов.
• Пользовательские функции: также предоставляются через SPI для замены зависимых параметров и проверки соответствия результатов вызова ожиданиям.

Другие примечания

Выражения для определения результатов вызовов и зависимые параметры используют одну и ту же систему правил. Подход основан на простоте и удобстве использования, без необходимости определять типы переменных или поддерживать операторы. Все выражения абстрагируются в виде функций (система предоставляет набор стандартных функций, а также поддерживает пользовательские функции через SPI). Для зависимых параметров возвращаемые значения могут использоваться для замены соответствующих параметров. Для выражений, определяющих результаты вызовов, возвращаемое значение должно быть логическим типом, указывающим на успешность вызова. Если возвращается несколько значений, они объединяются с помощью операции. Подробные инструкции можно найти в примерах по умолчанию.