Эволюция нашего использования XSLT в SOAP-тестах

В нашей системе есть SOAP-методы и есть автотесты на них. В автотестах применяются файлики transform.xslt — чтобы можно было переформатировать ожидаемый результат и проверять только те поля, которые нужны нам в данном тесте.

См также:
Folks — open-source проект с API-тестами на Java → там есть пример автотеста на SOAP с transform.xslt

Этап 1. Сортировка

Сначала мы использовали transform.xslt для сортировки данных. Просто чтобы тестировщик мог указать в response.xml поля в любом порядке, чтобы перестановка местами не приводила к падению. А потом начали трансформировать ответы...

Этап 2. Исключение часто меняющихся полей

Исходно мы начали применять трансформацию для исключения строки из проверки. У нас есть стандартизация адресов, которая определяет кучу параметров, в том числе код КЛАДР или ОКАТО. А они могут меняться...

Раньше у нас было мало интеграционных тестов, проверяющих все поля, а теперь они есть в каждом из 20 заказчиков, причем по несколько штук (на каждый тип контрагента). И вот если вдруг в КЛАДР / ФИАС что-то поменялось, тестировщику приходится ходить и уныло актуализировать тесты. При том, что эти тесты не про кладр-код, они про другое. На тестирование кодов КЛАДР есть другие тесты.

Так что нам надоело поднимать интеграционники каждый релиз, и из проверки адреса выкинули коды и дату актуальности КЛАДР (тоже с каждым обновлением менялась):


<xsl:apply-templates select="@* |
         cdi:field[
         @name!='kladrActualityDate' and @name!='kladrCode' and @name!='okatoCode'
]">

Этап 3. Исключение новых полей

Потом мы стали исключать новые поля, которые добавлялись в билд. Сначала актуализировали тесты, но бывает, что у Заказчика SOAP-тестов почти нет (все проверяется в core, основном модуле), а бывает, что у Заказчика несколько своих кастомных методов. И штук 20 тестов на каждый.

Вот добавляешь новое поле, оно появляется во всех response.xml... Подняли раз, подняли два, подняли три... Надоело! В итоге в чек-лист добавления нового поля внести отдельный пункт: «Добавить исключение поля в корневой transform.xslt, чтобы не развалились все SOAP-тесты».

<xsl:apply-templates select="@* |
         cdi:field[
         @name!='newField'
]">

Этап 4. Проверка только нужных полей

А потом мы стали в тестах на логику метода проверять не весь ответ, а только нужные поля. Так улучшилась читаемость тестов, полей ведь бывает много... Поэтому теперь у нас есть тест, который проверяет все поля ответа, и все остальные, где есть только важные с точки зрения логики поля:

<xsl:apply-templates select="cdi:field[@name='surname' or @name='name' or @name='patronymic']">

Этап 5. Рефакторинг прошлой записи

Проверять только нужные поля — нравится! Писать унылое «@name = ... or @name = ...» для каждого поля — нет.

Переделали в более читабельный вид. В начале файлика идет перечисление всех нужных полей

<xsl:variable name="fieldsToCopy">|birthdate|birthdateQC|birthdateRawSource|fullNameQC|</xsl:variable>


А потом мы указываем, что нам нужны все поля переменной fieldsToCopy

<xsl:apply-templates select="cdi:field[contains($fieldsToCopy, @name)]">
      <xsl:sort select="@name"/>
 </xsl:apply-templates>


Под конец еще раз напомню, что поиграться с XSLT в автотестах можно в бесплатном приложении Folks ツ