С какими форматами данных вы работаете в автоматизации тестирования?

А, ну это ж классика, блядь! Автоматизация тестов — это как поход в магазин: если ты идёшь за хлебом, то не тащишь с собой, сука, мешок для картошки, верно? Формат выбираешь под задачу, а не потому что он модный, ёпта.

Смотри, вот как у меня в хозяйстве всё устроено, на примерах, чтобы не быть пиздаболом:

1. Для всяких APIшных дел и настроек — JSON и YAML, короли и боги.

• JSON — это как родной язык для любого API. Запрос отправил, ответ получил — всё прозрачно, как слёзы ребёнка, которого только что отлучили от титьки. Парсится одной левой.

  // Вот смотри, RestAssured, Java, красота
  String jsonBody = """
  {
      "username": "test_user",
      "email": "user@test.com",
      "active": true
  }""";
  
  Response response = given()
      .contentType(ContentType.JSON)
      .body(jsonBody)
      .post("/api/users");

  Отправил — и сиди, жди, когда сервер тебе что-нибудь пиздатое ответит. Проще некуда.

• YAML — это когда JSON'у надоело быть угловатым, и он решил стать йогом. Читается легче, комментарии можно впихнуть, и в конфигах (типа docker-compose.yml) он живёт постоянно. Идеально, когда нужно, чтобы даже менеджер, случайно заглянувший в файл, не спросил «а это что за хуйня?».

2. Чтобы тесты параметризовать — CSV/Excel, рабочие лошадки. Тут всё просто: нужно сто тысяч комбинаций логинов-паролей? Берёшь Excel, набиваешь туда данные, а потом, блядь, скармливаешь это всё тестам через opencsv или pandas. Особенно кайфово, когда тестовые данные тебе готовят аналитики — они в таблицах как рыба в воде, а ты потом просто читаешь и ебешь систему напропалую.

3. Веб и отчёты — HTML/XML, старички-боровички.

• HTML — конечно, для UI-тестов лучше селекторы использовать, но иногда надо страницу распотрошить, как тухлую курицу, и посмотреть, что внутри. Тогда парсишь.
• XML — это такой формат, который говорит: «Я ещё жив, сука!». Встречается в древних SOAP API или таких же древних конфигах. Парсишь его через JAXB или ElementTree и чувствуешь себя археологом, который откопал говняный горшок.

4. Логи и всякая служебная хуйня — текстовые файлы и .properties.

• Текстовые логи — это святое. Тест упал? Первым делом лезешь в логи и ищешь, где система обосралась. Это как детектив: ищешь улики в куче словесного поноса.
• Properties / .env файлы — тут живут все секреты: пароли, ключи, урлы. Хранить это в коде — это прям приглашение наёбщику со стороны, чтобы он всё твоё добро спиздил.

А теперь, блядь, практическая философия:

• Конфиги и сложная хрень? Без вариантов — YAML или JSON. Структура есть, читаемость есть, инструменты для работы есть. Красота.
• Тонны тестовых данных? CSV или, на худой конец, прямое подключение к тестовой базе. Главное — не выёбываться.
• API? Для REST — JSON, для SOAP — XML, как бы тебе ни было за него обидно.

Итог, ёпта: выбираешь не то, что модно, а то, что меньше всего будет тебе, твоей команде и твоему CI/CD пайплайну ебать мозг. Всё гениальное — просто, как три копейки. А если сложно — значит, ты где-то уже накосячил.