Когда гоняешь тесты, самое бесящее — это сидеть и тыкать в прогон каждые пять минут: закончился или нет. Куда приятнее просто получить сообщение в Slack. Отвлекаешься меньше — в потоке сидишь дольше. Так что уведомления о результатах прогонов — это не украшение, а реальное удобство в работе с тестами.
В Allure Report такое прикрутили аж в версии 3.0 — через плагин для уведомлений в Slack. А в руководстве разжёвано, как настроить канал в Slack, чтобы каждый запуск Allure Report скидывал туда сводку по результатам.
Статья про то, как в ОС «Нейтрино» наладили сбор покрытия кода. Когда проект маленький, тут ловить нечего: поднял сборку с coverage, прогнал тесты, забрал отчёт — и свободен. А вот когда это целая операционка, где компонентов и тестов тысячи, всё превращается в отдельный квест.
Авторы раскладывают весь маршрут: от сборки компонентов и вылавливания файлов .gcno и .gcda до сборки трассировочных файлов и склейки результатов из разных CI/CD‑конвейеров. Плюс разбирают, как именно формируются итоговые отчёты.
И отдельным пунктом — зачем в будущем уходить с lcov на gcovr. Ознакомиться
Claude Code у ваших кодеров — это еще не автоматизация разработки
Прикинь: в команду взяли бодрого мидла. Трекер ему не открыли, базу знаний не показали, а про архитектурные решения рассказали один раз — на онбординге, и все. Дальше его изредка дергают: «погугли вон то». Иногда подкидывают мелкую фичу — в полном отрыве от общей картины. А потом прилетает за то, что он не въехал ни в таску, ни в то, как у вас тут все заведено. Вот примерно так я и вижу внедрение нейронок в разработку.
Дальше — про грабли, которые вылезают при вкатывании агентской разработки в процессы, и неважно, сколько у вас людей и какого размера контора. Плюс про то, что я наработал сам и подсмотрел у других за годы парного программирования с компьютерами.
Как тестировать API с 202 Accepted и не пропускать сбои фоновой обработки
Прилетел 202, автотест зелёный, все выдохнули. А через несколько дней выясняется: часть операций так и не дошла до успешного финала. Знакомо? Причина банальная — ты смотришь только на ответ HTTP-обработчика, а вся асинхронная цепочка при этом висит без контроля.
Ниже — как собрать нормальный тест для API с polling: старт операции, проверка статуса, валидация финального результата и аккуратный повторный запрос.
Тестирование API: 20 проверок, которые обязан уметь каждый QA
Чаще всего «тестирование API» — это кинуть запрос и порадоваться, что прилетело 200. На собесе такой подход живёт минуты две. А вот на проде вылезает то, чего код ответа в упор не видит: в ответе чужой заказ, вместо ошибки валидации — тихий 500, товар со склада так и не списался.
Дальше — 20 базовых проверок. Именно они отделяют того, кто реально тестит API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы. И всё это на одном сквозном сценарии, с примерами на curl и в Postman.
Новичок соберёт себе порядок действий, опытный — сверится и поймёт, куда расширять набор тестов.