Комментарии 12
Коллега, насколько понимаю, вы занимаетесь (авто)тестированием и увидели потенциал еще большей замены мануального тестирования на программное, что отрадно (и то то, делитесь опытом, тоже).
Комментирование работы с JMeter как таковым оставлю коллегам, компетентным в этой области, а со своей стороны поговорю о предложенном Java коде.
В целом хорошо написано для быстрого опыта, при этим есть, что улучшать:
Самая крупная ошибка (и, пожалуй, единственная) ошибка — то, что вы пытаетесь распарсивать XML файл вручную построчно.
Почему так не надо делать — долго объяснять, почитайте об XML и XSD.
А как надо: читать XML-файл с помощью XMLReader, или преобразовав его в DOM.
И кстати, не совсем ясно, что именно вас уберегло от использования XPath.
Если нет готового движка, то XPath — еще один способ читать этот файл, и он проще в написании/чтении/поддержке, чем XMLReader/DOM.
И кстати, не совсем ясно, что именно вас уберегло от использования XPath.Регулярные выражения показались достаточно универсальным и надежным средством. Я с ними практически не имел прежде дел и это было еще одним поводом «покурить» тему.
Регулярные выражения показались достаточно универсальным и надежным средством. Я с ними практически не имел прежде дел и это было еще одним поводом «покурить» тему.
Изучить тему — да.
Но, если говорить о коммите своих опытов в прод, то, работая через регулярки с XML, вы спускаетесь на другой, более «физический» уровень абстракции работы с XML, реализуя все вещи самостоятельно.
Предусмотреть все в своем «велосипеде» не получится — например, предусматривают ли разработанные выражения парсинг для случая, когда содержимое элемента содержит экранированные символы (чтобы не возникло конфликта с тегами разметки)?
предусматривают ли разработанные выражения парсинг для случая, когда содержимое элемента содержит экранированные символы (чтобы не возникло конфликта с тегами разметки)?Если я правильно понимаю, о чем вы — нет, не предусматривает. Если в названиях объектов использовать сложные символы (например, >), JMeter «под капотом» их сконвертирует и использование xpath эту проблему также не решит.
А реализуя свой парсинг, придется учитывать правила экранирования спецсимволов, и искать что-то вроде %код_символа%.
Или как вы будете (и будете ли) обрабатывать тег !CDATA (в который можно поместить текст «как есть» без экранирования)? — выведете !CDATA[текст] вместо «текст»?
Еще порадовало, что вы корректно освобождаете неуправляемые ресурсы, и для BufferedReader сделали это с помощью The try-with-resources Statement
Желательно так же сделать и для FileWriter, вместо примененного классического бойлеплейта с try-finally.
И еще замечание:
Объекты типа File не следовало помещать в контанты. От константы здесь только неизменяемость ссылки на объект.
А сам объект — "сложный", с изменяемым состоянием, и, хуже, того, позволяющий изменять внешний неуправляемый ресурс (физический файл).
В константы здесь нужно выносить пути к файлам, а сами файлы (File) создавать в коде.
И если уж совсем по-хорошему, стоит все вынести из метода main класса приложения в отдельный осмысленный по обязанности (см. SOLID) класс, объявить в нем один основной публичный метод, и декомпозировать его на пару приватных методов — работу с BufferedReader и FileWriter.
И в обработке исключений и прочих ситуаций не обращаться напрямую к выводу в консоль, а прокидывать в методы лямбду-стратегию (или создать в классе поле-стратегию) для делегирования логгирования.
Могу посоветовать попробовать YAML-синтаксис. Он не будет уступать текстовому представлению по понятности. И кроме того, тесты в таком представлении можно будет сразу же запускать, используя taurus.
gettaurus.org/docs/JMX2YAML
Есть ли этот код на GitHub?
Текст кода в статье это последняя, актуальная версия или есть более новая?
Экспорт дерева тестов из JMeter в текст