Показаны сообщения с ярлыком XSLT. Показать все сообщения
Показаны сообщения с ярлыком XSLT. Показать все сообщения

суббота, 28 апреля 2018 г.

Contains строки в XSLT

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

См также:
Folks — open-source проект с API-тестами на Java → там есть пример автотеста на SOAP с transform.xslt
Эволюция нашего использования XSLT в SOAP-тестах → подробнее про наши тесты


Формат записи у нас примерно такой. Вначале идет перечисление полей, которые я хочу увидеть в ответе

<xsl:variable name="fieldsToCopy">
        |surname|name|patronymic|fullNameRawSource|fullNameQC|
        fioTrusted|birthdateTrusted|innTrusted|snilsTrusted|
        </xsl:variable>

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

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

Так вот, запускаю я тест, он падает, ожидаемый ответ не совпадает с моим. Смотрю, почему — в actual_transformed_response.xml вижу дополнительные поля: inn и snils

Эволюция нашего использования 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'
]">