Не LLM едиными: генерируем юнит-тесты из реального исполнения на лету
Представьте себе: вы отлаживаете новый баг в сложном многослойном приложении (например, на Spring). Чтобы воспроизвести проблему, приходится взаимодействовать со всей системой end-to-end: отправлять запрос на эндпоинт или что-то кликать в UI. Юнит-теста, который бы изолировал нежелательное поведение до уровня злополучного сервиса или утилиты, нет. А хотелось бы, чтобы он был: во-первых, воспроизводить баг было бы проще (особенно если UI кликает QA, а не вы), а во-вторых, его потом можно было бы легко превратить в регрессионный и улучшить стабильность системы.
Интеграционные тесты в Go: как избавиться от флаков и боли
Всем привет! Меня зовут Александр Голубь, и я пишу на Go уже 7 лет. Когда я только начинал, казалось, что юнит-тестов достаточно. Функции проверены, сборка зелёная — можно релизить. Но первый же боевой проект показал, что это иллюзия. В продакшене всё падает, хотя юниты сияют зелёным. Почему? Потому что реальный сервис — это не только код, но и PostgreSQL, Redis, Kafka, внешние API. Данные проходят через цепочку зависимостей, и любая несовместимость ломает систему. Юнит-тесты этого не ловят. Тут нужны интеграционные.
