Абстрактный класс/метод/способ для проверки XML (Soap ответов)

tisaser · 04.Декабрь.2012 08:20:35

Вопрос скорее по Best Practies чем именно по SoapUI. С этом тулом работаю долго, так что хотелось бы услышать нетривиальные ответы/примеры.

Есть несколько веб-сервисов, которые по сути предоставляют SOAP интерфейс к другой системе/API/хранилищу (DB, SVN, LDAP, Fileserver etc). Ответы от сервисов могут быть разными и сложноструктурированными, с большим количством нод и субнод, значений (аттрибуты, как правило не используются).

Пример ответа (неполный :) ):

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

      <getJobResponse xmlns:ns3="http://eterra.com/asf/schema/common/v1" xmlns:ns2="http://eterra.com/asf/schema/tdm/common/v1" xmlns="http://eterra.com/asf/contract/tdm/dm/workflow/v1">

<JobVO>

<CreateTime>2012-11-09T20:09:28.532-08:00</CreateTime>

<Creator>mjcowley@vapps.esca.com</Creator>

<Description>build</Description>

<Id>16101</Id>

<JobProperties>

<Key>tdm.persistentParms</Key>

               <StringValue>tdm.siteCode,tdm.empVersion,tdm.componentDescription,tdm.habitatVersion,tdm.componentDependencies,tdm.buildNumber,tdm.componentVersion,tdm.userId,tdm.componentGroupName,tdm.environmentCode,tdm.componentName,tdm.componentTypeCode,tdm.jobId</StringValue>

</JobProperties>

<JobProperties>

<Key>tdm.empVersion</Key>

<StringValue>3.0</StringValue>

</JobProperties>

<JobProperties>

<Key>tdm.ets.dir</Key>

<StringValue>C:/eterra/e-terrasource</StringValue>

</JobProperties>

<Name>BuildEtb-16101</Name>

<StartTime>2012-11-09T20:09:28.696-08:00</StartTime>

<Status>Completed</Status>

<Steps>

<Id>16164</Id>

<Name>initialize</Name>

<ParentJobId>16101</ParentJobId>

<StartTime>2012-11-09T20:09:28.826-08:00</StartTime>

<Status>Completed</Status>

<StopTime>2012-11-09T20:09:41.313-08:00</StopTime>

<Tasks>

<Actor>tdm-agent@vapps.esca.com</Actor>

<Cancelled>false</Cancelled>

<End>2012-11-09T20:09:41.303-08:00</End>

<ExecutionHost>wx64mdl01:8080</ExecutionHost>

<JobId>16101</JobId>

<Open>false</Open>

<ParentStepId>16164</ParentStepId>

<Start>2012-11-09T20:09:28.904-08:00</Start>

<Suspended>false</Suspended>

<TaskInstanceId>16165</TaskInstanceId>

<TaskName>initialize</TaskName>

<Type>Command</Type>

</Tasks>

</Steps>

<StopTime>2012-11-09T20:09:52.143-08:00</StopTime>

<TimeoutLimit>-1</TimeoutLimit>

<WorkflowId>333</WorkflowId>

</JobVO>

</getJobResponse>

</soap:Body>

</soap:Envelope>

Название полей в БД/хранилище/API не совпадает с таковыми в ответе от сервиса (by design). Форматы значений естественно тоже разные (но это не так страшно).

Писать на каждую ноду XML и поле в БД свою строку кода для проверки значений, совсем не хочется. Хочется иметь таблицу развязки, с названием полей в ответе, в БД/хранилище/API и типом данных. Всё это я успешно сделал и работает. Теперь после изменений в названиях полей Soap ответа или структуре БД я меняю только таблицу развязки и все скрипты проверки работают снова. Т.к. у нас вездесущий scrum, то меняем мы это каждый билд :), а проектов у нас в комманде много, а людей мало. Ну это как и у всех, собсна.

Вопрос состоит в следующем, делал ли, кто нибудь такую таблицу развязки, чтобы учитывалась еще и иерархическая структура ответа? То есть таблица развязки должна учитывать не только название и типы полей, но также и структуру ответа. Скрипт проверки должен понимать эту развязку с учетом иерархии объектов. Согласно этого конечно придется строить и запросы к хранилищу (DB, SVN, LDAP, API etc) напрямую. Также нужно учитывать, что в разных нодах (классах хрнилища) можгут быть одинаковые названия полей (субнодов). К примеру Name или ID очень популярное название поля:)

Вообщем, вопрос бОльше для обсуждения наверное, ну а вдруг кто придумал универсальное решение и поделится с нами.

Taras · 04.Декабрь.2012 18:16:06

Можна например что сделать, парсить сабноду в обьект. Если не парситься в обьект значит структура уже нарушена, имхо ассерт не пройдет.

JSON парсить в обьекти можна JAckson-ом, XML - ищите в нете. Просто если кусок стринга не розпарситься етой либой в обьект класса вашей заданой структури то вальнеться ексепшн, которий можна перехватить в тесте например - ето считаю и будет критерием проверки на архитектуру.

tisaser · 05.Декабрь.2012 08:57:27

Наверное я не до конца рассказал что именно надо. Для проверки именно структуры (и частично значений) XML есть xsd что умело юзает SoapUI в SchemaCompliance asserion.

Вопрос не в проверке структуры, а в проверке сложно-структурированной XML на основании хранилища данных.

К примеру имеем 2 таблички в БД

Groups и Peoples. Связь для простоты один ко многим (в одной группе несколько людей). Джойнятся таблички по простому ключу. Итого WS выдаст структуру типа

<root>

<group>group1

</group>

<group>group2

</group>

</root>

В БД поля называются не так как в ответе от WS. Задача нарисоваьт таблицу развязки, согласно которой результат работы SQL-запроса (который строится тоже на основании развязки) будет похож на ответ от сервиса.

Мне пока что видится только один вариант. Рисовать таблицу развязки с такой же структуруй как ответ от WS и на основании этой структуры стоить коллекцию (MapOfMap Map<Map>и т.д.), а потом уже итерироватся по коллекции и парсить XML. То есть по сути создавать такую же XML как и ответ от сервиса и сравнивать их.

KaNoN · 07.Декабрь.2012 17:51:12

Можно пойти по другому пути, учитывая, что SOAP сервисы - это по сути API с распределенной инфраструктурой и все эти XML-и это просто очередное представление некоторого типа данных. Любой из этих типов данных можно представить в виде множества таблиц со своими связями (эту структуру можно получить генерацией диаграмм классов). Соответственно, у вас есть 2 структуры: структура исходной базы и структура данных-ответов на запросы. Между этими структурами есть связь. Чтобы проверить целостность данных, нужно сделать запросы к обеим структурам и привести обе структуры к общему виду (не обязательно это представление одной из структур, это может быть любое производное представление). В итоге у нас есть 2 таблицы одной струкруры и нам останется только сравнить их (различными сортировками и группировками их можно подравнять). А дальше идет цикл сравнения.

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

tisaser · 07.Декабрь.2012 18:35:21

Да в принципе понятно все идеологически. Надо привести данные к виду ответа от сервиса и сравнить. Универсального решения я так и не нашел, но для каждого ответа который нужно проверять я строю структуру такого же вида как и ответ на основании первичного источника данныхи уже рекурсивно проверяю ответ.
А почему Вы считаете что SoapUI плохо подходит для проверки Soap ответов?

KaNoN · 09.Декабрь.2012 12:05:52

Я считаю, что SoapUI плохо подходит для реализации подхода, который описал я, так как я сделал больше упор именно на структуры данных с отвязкой от XML. Поскольку SoapUI не преобразует ответы в пригодные для работы типы данных напрямую, то из-за этого я и высказался, что SoapUI плохо с такой задачей справится.

Если глянуть шире и посмотреть, как SOAP сервисы используются, то тут уже возникнет отдельный вопрос, а насколько хорошо SOAP UI подходит для тестирования этого всего. Но это уже отдельная тема, на самом деле.