En

JazzTeam Software Development Company

Agile Java Development

Виды и особенности тестирования Mule-коннектора

Введение

Тестирование Mule-коннектора является необходимой стадией его реализации. Рассмотрим следующие различные виды тестирования:

Функциональные тесты, целью которых является проверка правильности поведения коннектора (работа процессоров и методов, работающих с метаданными, операций с WSDL и т. д) в различных версиях Mule. Таким образом, эти тесты служат для проверки совместимости с другими версиями Mule.

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

Юнит-тесты хоть и не являются обязательными, но мы рекомендуем их использовать для тестирования отдельных фрагментов кода, которые остались непокрытыми после выполнения системных и функциональных тестов.

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

Для подготовки к сертификации Mule-коннектора обязательными видами тестов являются системные и функциональные тесты. Согласно правилам сертификации Mule-коннекторов покрытие кода тестами должно быть больше 70%. Если системные и функциональные тесты не покрывают код на 70%, то для увеличения покрытия могут использоваться юнит-тесты.

С примером реализации системных и функциональных тестов можно ознакомиться в референс-проекте по реализации Mule-коннектора к социальной сети VK.

Организация тестов на уровне пакетов

Для прохождения сертификации нужно использовать строго определенную структуру пакетов:

  1. org.mule.modules.<connector-project>.automation.runner - содержит все TestSuites (FunctionalTestSuite, SystemTestSuite).
  2. org.mule.modules.<connector-project>.automation.functional - содержит все функциональные тесты.
  3. org.mule.modules.<connector-project>.automation.system - содержит все системные тесты.
  4. org.mule.modules.<connector-project>.automation.unit - содержит все юнит-тесты.

Для различных утилитных классов может быть использован пакет org.mule.modules.<connector-project>.automation.utils.

Конфигурация тестов

Для выполнения тестов и осуществления соединения к внешнему сервису необходимо создать файл с properties, который должен находится в директории src/test/resources. По умолчанию этот файл имеет имя automation-credentials.properties. Также этот файл может задаваться при запуске теста с помощью опции -Dautomation-credentials.properties=FILENAME

Функциональные тесты

Функциональные тесты обязательно должны присутствовать для прохождения сертификации. Эти тесты должны покрывать код всех процессоров, классов работающих с метаданными, операций с WSDL и методов, помеченных аннотациями @Source и @Paged. Для этого Mule предоставляет фреймворк для тестирования коннекторов (Connector Testing Framework - CTF).

Структура класса, использующего CTF

Имена функциональных тестов обязательно должны иметь окончание TestCases. Например, CreateEntityTestCases.
Все классы с тестами, которые используют CTF, должны наследоваться от класса AbstractTestCase и вызывать конструктор родительского класса.

Как вариант, можно создать отдельный класс, который будет наследоваться от AbstractTestCase, вызывать конструктор родительского класса, создавать данные для тестов. Тогда этот класс будет родительским для классов с различными тест-кейсами.

В методе setup(), помеченном аннотацией @Before, производится создание необходимых данных. Для генерации тестовых данных нужно в пакете org.mule.modules..automation.functional создать класс TestDataBuilder.java, который будет возвращать необходимые данные:

В методе tearDown(), помеченном аннотацией @After, происходит возврат sandbox в исходное состояние.

Тестирование процессоров

Каждый процессор коннектора по возможности должен быть покрыт тестами.
Класс с тестами для процессоров должен иметь ту же структуру, что и все классы, использующие CTF.

Тест-кейс для процессора выглядит следующим образом:

Для вызова операции коннектора нужно получить объект коннектора с помощью метода getConnector(), который предоставляется CTF.

Тестирование DataSense

При разработке коннектора для системы управления мастер-данными мы использовали динамический DataSense. Тестирование DataSense осуществлялось следующим способом:

Каждый DataSenseResolver коннектора по возможности должен быть покрыт тестами.

Класс с тестами для DataSense должен иметь ту же структуру, что и все классы, использующие CTF.

Класс для тестирования DataSenseResolver должен иметь имя MetaDataTestCases и должен содержать два теста: testMetaDataKeys and testMetaData.

CTF предоставляет метод getDispatcher(), который позволяет получить объект CTF-диспетчера. В свою очередь, этот диспетчер имеет методы fetchMetaDataKeys() и fetchMetaData(keyName). Первый метод извлекает все ключи метаданных, второй метод извлекает метаданные для определенного ключа.

Пример теста:

Методы testMetaDataKeys и testMetaData обязательно должны быть помечены аннотацией @MetaDataTest.

Добавление тестов в TestSuite

Все функциональные тесты должны быть добавлены в TestSuite с названием FunctionalTestSuite. Если есть несколько TestSuites (например, тесты разделены логически в разные TestSuites), то их нужно объединить в FullFunctionalTestSuite.

Пример FunctionalTestSuite:

В аннотации @SuiteClasses должны быть перечислены все классы с тестами (тесты процессоров, метаданных и т.д). В методе initialiseSuite() происходит инициализация контекста коннектора и инициализация CTF в целом. В методе shutdownSuite() происходит освобождение ресурсов CTF.

Системные тесты

Данные тесты являются обязательными для прохождения сертификации. Этот вид тестов включает в себя все тесты, которые не являются функциональными, но при этом требуют наличие соединения. Например, тестирование с неправильным паролем или логином, некорректным адресом сервера авторизации и т.д.
Для проведения системных тестов берутся валидные properties из файла automation-credentials.properties, который используется в функциональных тестах, и после этого часть корректных данных изменяется на некорректные.

Каждый класс с конфигурацией соединения должен быть протестирован. Класс для тестирования конфигурации должен иметь имя TestCases. Все системные тесты должны быть добавлены в SystemTestSuite аналогично тому, как это делалось с функциональными тестами.

Пример системного теста:

Юнит-тесты

Юнит-тесты не обязательны для сертификации коннектора. Однако, если после выполнения функциональных и системных тестов, остались участки кода, которые нужно покрыть тестами, то для этого можно использовать юнит-тесты.

Имена для юнит-тестов должны быть выбраны с учетом конвенций именования JUnit (имя класса должно оканчиваться словами Test или TestCase). Объединять юнит-тесты в TestSuites не обязательно.

Запуск тестов

Тесты можно запускать при помощи Maven из командной строки или в Anypoint Studio.

Пример команды для запуска системных тестов из Maven:
mvn surefire:test -Dtest=SystemTestSuite

Результат команды:

Для запуска тестов в Anypoint Studio нужно нажать правой кнопкой мыши на тест или TestSuite, Run As -> JUnit Test.

Результат выполнения тестов в студии выглядит следующим образом:

 Нагрузочные тесты

Нагрузочные тесты также не обязательны для сертификации коннектора, но могут быть использованы для изучения поведения коннектора в случае интенсивного использования и изучения производительности коннектора. В качестве одного из средств для проведения нагрузочного тестирования можно использовать Apache JMeter. В этом случае можно построить Mule flow, который использует коннектор, и имеет в качестве точки входа в приложение HTTP listener connector:

JMeter в этом случае будет делать вызовы по адресу, установленному в http-коннекторе.

Результаты работы JMeter:

Также можно сделать сравнение времени работы коннектора с результатами работы тех компонентов, которые являются частью Mule (например, Http или Database коннектор). На основе этих результатов оценить производительность коннектора и сделать выводы о необходимости оптимизации работы коннектора.

Пример flow для тестирования коннектора:

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

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *