Всем привет!

Формат yaml все больше входит в нашу жизнь, самые очевидные примеры - k8s, Docker Compose и Ansible.
Его главным преимуществом я считаю ссылки - соблюдается принцип DRY.
Главным недостатком - зависимость от числа tab\пробелов как в Python.

А чтобы не дать лишнему пробелу все сломать - нужна валидация.

Для начала - валидация синтаксиса https://yamllint.readthedocs.io/en/stable/index.html
Хотя в списке ОС для скачивания нет Windows - он ставится на Win с помощью python + pip.
Также есть плагин для IDEA https://plugins.jetbrains.com/plugin/15349-yamllint

Да, подсветка синтаксиса хотя и не заменяет валидацию, но тоже полезна - IDEA, Notepad++ и Atom поддерживают его из коробки.

Далее можно прикрутить валидацию, специфичную для конкретной области применения.
Для k8s есть утилиты kubeval, kube-score и Polaris см. https://habr.com/ru/companies/flant/articles/511018/
Они проверяют манифесты на соответствие best practices.
В docker-compose валидация вызывается с помощью команды https://docs.docker.com/engine/reference/commandline/compose_config/
Для Ansible - базовые проверки встроены в Ansible, также есть ansible-lint, детали см. https://www.deploymastery.com/2023/03/31/how-to-verify-ansible-playbook-syntax/

Альтернатива - написать нужные проверки самому. Тут есть 4 библиотеки из уже приведенной выше статьи:
config-lint, copper, conftest, Polaris
https://habr.com/ru/companies/flant/articles/511018/ Основное различие - в языке, на котором будет ваш код проверки. Есть и декларативный yaml, есть и императивный JS.

#yaml #k8s #ansible #docker-compose #validation

Всем привет!

Продолжим про тестовые библиотеки. Достаточно часто возникает задача проверить в тесте структурированные текстовые данные. Я про XML, json и yaml как самые распространённые варианты. XML первым указан по старшинству, а не распространённости) И он пока ещё жив.

Зачем для этого нужно специализированная библиотека:
1) текст может отличаться формированием - пробелами и переносами строк. Иногда это важно при сравнении, но часто нужно проигнорировать
2) могут быть «лишние» тэги/атрибуты - которые не должны участвовать в сравнении
3) может отличаться порядок тэгов
4) может стоят задача проверить только отдельные элементы в дереве, или их количество

Одной библиотеки для всех форматов нет, но есть две - XMLUnit и JsonAssert. Так думал я, пока не начал копать тему глубже. И искать, чем же можно проверить yaml. Оказывается, есть «более лучшая» замена JsonAssert, которая:
1) умеет и в json, и в yaml, причём может сравнивать json и yaml. И также сравнивать с Java обьектом
2) умеет все это делать в стиле Assert/Truth, он же method chaining. А это облегчает как написание условий проверки благодаря auto competition в IDE, так и их чтение. А возможно в некоторых случаях позволит отказаться от BDD фреймворка.
3) прозрачно работает с разными источниками данных - строка и файл
Встречайте - ModelAssert https://github.com/webcompere/model-assert
И более подробно https://www.baeldung.com/json-modelassert
Что интересно - автор сам написал статью на baeldung и ссылается на неё в документации.
Ещё важный момент - подчеркивается совместимость библиотеки со Spring MockMvc и Mockito. Возможно даже ради этой поддержки автор и запилил совместимость с Hamcrest. И последнее - отдельно продумано тестирование json с guid. Во-первых можно игнорировать различия конкретных значений uuid (они могут генерироваться в каждом тесте), во-вторых легко написать проверку формата uuid.

А что же XML - вот хорошая статья по XMLUnit https://www.baeldung.com/xmlunit2
Он может примерно то же самое, но без method chaining. Но зато с валидацией по схеме (xsd). Что кстати неплохо характеризует отличия в подходах к работе с XML и json)

#unittests #rare_test_libs #XML #json #yaml