#qa_automation — Public Fediverse posts

Kafka Consumer в тестовой автоматизации: архитектурный разбор

Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка. End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается. В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом. Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

https://habr.com/ru/companies/it_sense/articles/1051890/

#kafka #kafka_consumer #kafka_в_тестировании #qa_automation #sasl #асинхронное_тестирование #aiагенты #allure #consumer_group #распределенные_системы

Cucumber должен умереть: Как с помощью BDR превратить код в отчеты без регулярок и регистрации?

В прошлой статье «Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?» мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход. Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации... Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты. Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting) . Почему классический BDD (Gherkin) - это ошибка? Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

https://habr.com/ru/articles/994732/

#playwright #bdr #bdd #allure_report #qa_automation #чистый_код #автотесты #автотестирование #автотестировщик #автоматизация_тестирования