Правила Well Formed XML

Это выдержка из моей статьи «Что такое XML»

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

1. Есть корневой элемент.
2. У каждого элемента есть закрывающийся тег.
3. Теги регистрозависимы!
4. Соблюдается правильная вложенность элементов.
5. Атрибуты оформлены в кавычках.

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

Что такое XML

Если вы тестируете API, то должны знать про два основных формата передачи данных:

• XML — используется в SOAP (всегда) и REST-запросах (реже);
• JSON — используется в REST-запросах.

Сегодня я расскажу вам про XML. В списке доп литературы будет ссылка на книгу по XML, у меня нет цели ее дублировать, но я расскажу про этот формат тем, кто XML еще в глаза не видел. А дальше уже гуглим сами ))

Ссылка на Хабр (там содержание кликабельное)

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:

Что такое API — общее знакомство с API

Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.

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'
]">