Привет, Хабр! Меня зовут Михаил, я SDET-специалист компании SimbirSoft. Я занимаюсь автоматизацией тестирования, в основном это работа с WEB и REST API. Но на последнем проекте использовался SOAP, поэтому при автоматизации тестирования я работал с сообщениями этого протокола, а именно: выполнять проверку наличия обязательных атрибутов и тегов SOAP сообщений; сравнивать содержание различных сообщений; вносить изменения или генерировать новые сообщения для исходящих запросов. В своей статье я поделюсь несколькими способами работы с XML-документами. Материал будет полезен тем, кто впервые сталкивается  в работе из кода с подобными документами на Java. Для работы я преобразовывал SOAP сообщения в Java-объекты. Этот процесс называется демаршаллинг. Обратный процесс называется маршаллинг, как десериализация и сериализация JSON. Отличие маршалинга от сериализации заключается в том, что сериализация предполагает упаковку лишь данных программы. Например, при сериализации объекта класса, состоящего из полей и различных методов, сохраняться будет информация только о полях, а о методах — нет. При маршалинге объекта запишется не только информацию о его данных (полях), но и информация по восстановлению структуры объекта — класс объекта, либо его мета-информацию для реконструирования типа.  В Java существует множество инструментов и способов преобразования документов формата XML в объекты. Я выбирал между использованием JAXB и DOM.  В качестве примера приведу XML-документ со следующим содержанием: Это описание экрана некоторого продукта. Корневым элементом является <Screen>, содержащий в себе теги заглавия, описания экрана, а также блок кнопок и несколько атрибутов. Кнопки, в свою очередь, содержат заглавия и различное количество подсказок. В некоторых тегах есть атрибуты, описывающие состояние и  цвет элемента. А также команду “Action”, которую необходимо использовать при выполнении запроса на определенное действие. У данного продукта все формируемые экраны соответствуют единой схеме, отличия могут быть в содержании тегов, их количестве и значениях атрибутов. К примеру, на экране может быть больше или меньше кнопок с различными состояниями, атрибутами и др. JAXB (Java Architecture for XML Binding) — это специальный инструмент для маршалинга и демаршалинга объектов. JAXB предоставляет аннотации, которыми размечаются поля JAVA-классов.  Для начала необходимо создать требуемые классы.  Принцип получается примерно следующий: если тег имеет дочерние элементы или атрибуты, значит это объект. Если тег в документе не имеет дочерних элементов, значит это поле объекта. Корневой класс Screen: Он содержит в себе три строковых поля: “stage”, “title”, “description” и  коллекции “buttonList” и “attributeList”. 3 класса вложенных элементов: Всего нужно 4 класса. Теперь нам необходимо разметить наши поля и классы аннотациями, чтобы иметь возможность выполнять операции маршаллинга и демаршаллинга. В этом случае нам понадобятся следующие аннотации: — @XmlRootElement(name = "Screen") — определяет корневой элемент. Может быть указана над классом или полем класса; — @XmlAccessorType(XmlAccessType.FIELD) — определяет сущности, которые используются в процессах преобразования; — @XmlAttribute(name = "Stage") — определяет, что поле является атрибутом, а не тегом в XML-документе;  — @XmlElement(name = "Title") — определяет, что поле является тегом в XML-документе; — @XmlElementWrapper(name="Buttons") — создает некоторую обертку вокруг группы повторяющихся тегов; — @XMLValue — определяет, что поле содержит в себе значение тега. Получились следующие классы: В аннотациях, в параметре “name”, указывается имя тега XML, значение которого мы присваиваем полю объекта при маршаллинге.  А при демаршалинге этот параметр, наоборот, задает имя тега XML для значения поля объекта.  В примере сеттеры и геттеры реализованы через аннотацию Lombok @Data. Но в JAXB они не требуются и не используются. Таким образом, отсутствует возможность редактирования значений полей при преобразованиях. Но они нужны для других  стандартных операций с объектами. Для удобства во всех классах переопределен метод toString(). Вот так этот метод реализован в классе Screen: В остальных классах он переопределен аналогичным образом. Классы готовы к работе. Реализуем чтение документа XML. Для этого используем BufferedReader c  чтением из файла и StringReader, который будет считывать созданную строку в процессе преобразования.  После создаем JAXBContext — сущность, которая лежит в основе работы процессов маршаллинга и демаршаллинга. Это точка входа в API JAXB, она предоставляет абстракцию для управления информацией о привязке XML/Java. В качестве параметра при создании указываем класс получаемого объекта — Screen.class. С помощью JAXBContext создадим Unmarshaller, необходимый для преобразования XML-документа в объект Screen с приведением типа. Для этого в метод unmarshal() передается ранее созданный StringReader: Результат можно увидеть, развернув объект в окне отладки, или путем выведения в консоль — для чего и переопределялись методы toString(). Это был процесс демаршаллинга. Из документа (сообщения SOAP) получили объект Java с методами для работы, всеми полями и атрибутами. Создаем StringWriter, который будет записывать строку. Также создадим сущность Marshaller с установкой параметров форматирования данных. Чтобы проверить, что все работает, внесем изменения в полученный ранее объект screen: изменяется заголовок и цвет с описанием для первой кнопки. После чего в метод marshal() передаем объект и StringWriter: Теперь writer хранит в себе данные объекта screen в виде строки, с помощью которой можно перезаписать или создать новый XML-документ, либо сгенерировать сообщение SOAP.  Для просмотра результата можно воспользоваться окном отладки или вывести в консоль. Более подробно с JAXB можно ознакомиться тут.  Второй способ преобразований с использованием DOM (Document Object Model) в сравнении с предыдущим может показаться более трудным и запутанным. Здесь не используются аннотации для поиска и определения тегов и полей классов. При использовании DOM весь XML-документ представлен в виде древовидной структуры. Для перемещения по этой модели, получения узлов, значений имен тегов, их атрибутов и т.д. существуют специальные методы и сущности. Сначала также создаем классы: Основное отличие заключается в том, что для хранения атрибутов тега используется HashMap<> attributes. Теперь не важно, какие именно могут быть атрибуты у тега — при преобразовании они все будут добавлены в мапу в формате «ключ-значение». Здесь гетеры и сеттеры используются при преобразованиях. Можно написать свои и при необходимости реализовать в них изменения входных и выходных параметров.  Для начала немного об определениях некоторых сущностей, которые нам понадобятся. Важно понять, что основной «атомарной» единицей в этой модели является Node — узел.  Узлом может быть: Node — класс, который предназначен для любого XML-элемента: текст, тег, или атрибут. Т.е. все в XML есть Node. Далее идет специализация. NamedNodeMap — сущность, в которой хранятся данные «ключ-значение», она используется при получении атрибутов тега. NodeList — список узлов, используемый при получении дочерних элементов и узлов с одинаковыми тегами.  Пример кода по заполнению объекта данными из XML-документа с использованием DOM: Для удобства можно написать специальные классы-парсеры. В приведенном выше коде представлены некоторые методы, которые возможно для этого использовать.  Как такового обратного процесса, как в случае с JAXB, этот способ не подразумевает. Но есть переопределенный метод toString() объекта ScreenDom, который возвращает строку формата XML. Привести ее к нужному формату уже не составит труда. К дополнению метода описанного выше также используется XPath. XPath — это язык запросов к элементам XML. Он позволит создать выражение запроса и получить интересующие данные из документа. В своей работе при тестировании API я использую RestAssured и его поисковые выражения. Чтобы получить значение «Атрибут №1» из Response RestAssured, можно использовать следующий код: Поисковое выражение прочитаем следующим образом: во всем документе найти значение первого тега, у которого есть атрибут “A”, равный значению “BC”. Есть и другие способы и выражения XPath, поддерживаемые RestAssured: root.parent.child.grandchild;. root.parant.child[0]; (child[0]); root.parent[0]; it.@type == 'специфическое значение'; Вышеописанный способ отлично подходит для поиска определенных значений в XML-документе. Он не требует создания сущностей Java, применяется довольно легко и быстро. Но стоит отметить, что данный способ не подходит для полного процесса преобразования из документа в объект и обратно. Более подробно об использовании Xpath в RestAssured  вы можете ознакомиться в документации.  Весь код статьи доступен в удаленном репозитории по этой ссылке. Это рабочий проект, в котором реализованы оба способа маршаллинга и демаршаллинга. Кроме того, в нем реализован тест, пример возможного использования данных методов при автоматизации тестирования сообщений SOAP- или XML-документов. В этой статье я поделился своим опытом в решении некоторых задач, с которыми столкнулся при автоматизации тестирования сообщений SOAP. Это далеко не все способы и инструменты, доступные для преобразования XML на Java. Но они работают и их довольно легко понять и реализовать.  Каждый способ имеет свои плюсы и минусы. Для удобного восприятия я представил их в таблице ниже: Инструмент Плюсы Минусы JAXB Прост в реализации. Легкочитаемый код. Отлично подходит, если используется XML-схема. Возможно частичное использование. Нужно точно знать возможные атрибуты тегов. Нет возможности редактировать значения при преобразовании объектов.   DOM Нет необходимости заранее знать возможные атрибуты тегов. Возможность редактирования  значений при преобразовании объектов.  Гибкость в использовании. Сложная реализация. Иногда трудночитаемый код. В своем случае я выбрал DOM из-за неизвестности атрибутов тегов в получаемых сообщениях SOAP. Мне понадобилась возможность добавлять новые узлы в древовидную структуру документа при преобразованиях. При помощи методов DOM я реализовал классы — парсеры, которые позволили достаточно легко и просто выполнить маршаллинг и демаршлаллинг по необходимым мне условиям.  Надеюсь, эта статья была вам интересна. Спасибо за внимание! Рекомендуем другие наши SDET-статьи: Ускоряем работу с тестовой документацией. Экспорт данных из Allure-отчета в Confluence Как настроить Pipeline для Jenkins, Selenoid, Allure Что дает автоматизация тестирования От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте Авторские материалы для разработчиков мы также публикуем в наших соцсетях – ВКонтакте и Telegram.