Еще один DIY фреймворк для тестирования (часть 1 из 3) — Идея


Отказ от ответственности

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

Также автор не является лучшим в мире экспертом по фреймворкам тестирования Java, поэтому есть вероятность, что где-то в природе уже существует фреймворк, который решает все вопросы и лучше использовать вместо изобретения описанного ниже велосипеда.
(Если вы знаете такой, пожалуйста, дайте мне знать в комментариях)

Введение (Какую проблему мы решаем?)

В мире существует множество более или менее хороших фреймворков для тестирования. Некоторые из существующих фреймворков тестирования делают свою работу очень хорошо и являются де-факто стандартом, как «огурец» для BDD тестирования.

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

Идея

Техническая сторона

Java hava имеет встроенный скриптовый движок, который может быть использован для различных целей.
Этот встроенный скриптовый движок имеет ряд преимуществ для нашей задачи:

  1. Он очень прост в использовании. Минимальный пример использования — около 3 строк кода.
  2. Одним из скриптовых языков, реализованных в этом движке, а также встроенных в него, является JavaScript. Хорошо известный практически всем и чрезвычайно популярный в настоящее время.
  3. Этот движок имеет двунаправленный мост между Java и JavaScript (и на самом деле любым другим скриптовым языком, но здесь нас интересует JavaScript).

И некоторые недостатки, где наиболее важным является производительность. JavaScript код, выполняемый этим скриптовым движком, примерно в 500 раз медленнее, чем обычный Java. Конечно, это не производительность NodeJS, но эта производительность не является проблемой, принимая во внимание нашу область интересов.

Идея фреймворка

Идея довольно проста:

  1. Написать «исполнитель» для «тестовых скриптов», обогащенный полезными функциями для тестирования вашего приложения.
  2. Написать «бегунок для тестирования», который будет:2.1. Находить все «тестовые скрипты» из определенной папки2.2. Выполнять скрипты с помощью «executor» и собирать результаты2.3. Собирать отчет о тестировании из собранных результатов.

Фреймворк в деталях

Тестовый скрипт

Честно говоря, «тестовый скрипт» не является частью фреймворка, но в любом случае его необходимо объяснить.

Тестовый скрипт — это файл JavaScript, который тестирует некоторую функцию приложения.
Тестовый скрипт — это:

  • использовать дополнительные встроенные в «исполнителя» функции для взаимодействия с приложением
  • писать логи в stdout (чтобы упростить задачу «бегуна тестов» по сбору результатов)
  • отказ с исключениями в случае обнаружения некоторых проблем в тестируемом приложении.

Executor

Исполнитель — это Java-приложение, которое может выполнять JavaScript-файл, переданный туда в качестве параметра.
Дополнительно исполнитель должен иметь конфигурацию приложения, чтобы к нему можно было правильно подключиться.

В случае неудачного выполнения сценария, Executor должен завершить работу с ненулевым кодом выхода.

Бегунок для тестирования

Это приложение, реализованное на любом языке, который вам нравится (для последовательности лучше реализовать его на Java или JavaScript, чтобы минимизировать количество различных технологий, которые должны знать разработчики).

Test Runner сканирует папку с тестами и выполняет файлы из нее с помощью Executor.

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

Бегунок для каждого выполненного скрипта собирает:

  1. Вывод из stdout (журналы и ошибки)
  2. Код выхода скрипта
  3. Время выполнения

После выполнения всех тестов (скриптов) вся собранная информация может быть собрана в один отчет (или несколько отчетов в случае параллельного выполнения тестов).

Отчет представляет собой документ в выбранном вами формате (HTML, PDF, DOC, TXT и т.д.) со списком тестов и их статусом.

В конце выполнения тест-раннер должен завершиться с ненулевым кодом выхода, если хотя бы один тест не прошел.
(Это упростит интеграцию с внешними CI/CD системами).

Как это должно работать (пример)

Например, если наш фреймворк тестирования состоит из двух java-частей:

  1. Исполнитель — test-executor.jar
  2. Test Runner — test-runner.jar

И у нас есть следующий список тестов:

tests/
  Test_endpoint1_get.is
  Test_endpoint1_post.js
  Test_endpoint1_delete.js
  Test_endpoint1_auth.js
Войти в полноэкранный режим Выйти из полноэкранного режима
  1. Выполняемые тесты будут следующими
$ java -jar test-runner.jar tests/
Войти в полноэкранный режим Выход из полноэкранного режима
  1. Выполнение одного тестового сценария будет выглядеть следующим образом
$ java -jar test-executor.jar tests/Test_endpoint1_post.js
Войти в полноэкранный режим Выход из полноэкранного режима
  1. Отчет по всем тестам будет выглядеть следующим образом
Tests report:
tests/Test_endpoint1_get.is - ok (0.05sec)
tests/Test_endpoint1_post.js - ok (0.10sec)
tests/Test_endpoint1_delete.js - ERROR (exit code - 1)
  … Detailed log of error …
tests/Test_endpoint1_auth.js - ok (0.03sec)
Вход в полноэкранный режим Выход из полноэкранного режима

PS: Пожалуйста, дайте мне знать, если вам понравилась идея и вам будет интересно увидеть реализацию этого фреймворка.

Оцените статью
Procodings.ru
Добавить комментарий