Комментарии 10
Спасибо, вполне практически полезная информация про Qodo‑Cover. Пока вручную пишу запросы для генерации тестов, результат разный, но ускоряет рутину это точно. Хотя проект Qodo‑Cover, написали, уже не поддерживается, но надо поиграться с ним и проверить концепцию.
Вот что случается когда корпоративное мышление (точнее - отсутствие такового и замена мозга на KPI) получает доступ к LLM! Что вы носитесь с метриками покрытия как с карго-культом ?! Я уже устаю воевать с этой тупостью: покрытие - это метрика, а, блдж, не цель! Она не может быть ни плохой, ни хорошей. Если у вас низкое покрытие - то надо не LLM запускать чтобы она сделала покрытие (напоминаю, можно легко сделать тест который на 100% покрывает кусок кода, и никогда не падает - для этого достаточно ничего не ассертить!) - а садиться и разбираться почему так! То-ли архитектура не позвляет писать юнит-тесты, то-ли нет нетривиальной логики, то-ли еще какая причина...
Мы тоже делаем тесты при помощи LLM - но при этом кучу времени и экспериментов потратили на то чтобы а) Отсечь файлы на которые юнит-тесты писать не надо даже пытаться; и б) Заставить систему сначала описать тест-кейс словами в формате given-when-then, и только потом его реализовывать. Чтобы тестировались какие-то реальные кейсы, а не тупо набивались проценты покрытия...
А когда при помощи LLM набиваются проценты покрытия в угоду корпоративным KPI - то LLM вам просто к столу прибивает детали реализации. Когда вы потом начнете это рефакторить - будете плакать горючими слезами. Потому что в нормальных юнит-тестах прибито к столу требуемое (!) поведение системы. Которое если сломалось - значит где-то что-то в другом углу упадет. А после LLM - тестами система заморожена в текущем состоянии. Поди пойми, что связано с реальным поведением системы, а что - нет ?... И тогда будет второй этап - вы после изменений удалите красные тесты и попросите систему восстановить процент покрытия. Только вот ИИ без разницы что вы там написали в новом коде - он прибивает к столу некорректное поведение так же эффективно как правильное. В конце вы сможете насладиться выкидыванием тестов оптом на помойку (потому что теперь никто не знает какое поведение они фиксируют), и начать руками заново...
Мы как раз подчёркиваем, что 100% покрытие — не цель само по себе:
Важно понимать, что 100 % покрытие — это не гарантия идеального кода. Можно добиться полного покрытия, написав формальные тесты, которые ничего по сути не проверяют. Такие тесты создают лишь иллюзию надежности. Поэтому стремиться нужно не к цифрам ради цифр, а к осознанному покрытию — когда тесты действительно проверяют ключевую логику и помогают находить ошибки, а не просто «заполняют статистику».
Цель статьи — показать, как можно использовать LLM, чтобы снизить рутину и сделать тестирование дешевле и эффективнее, не теряя при этом здравого инженерного подхода. Мы не предлагаем бездумно покрывать всё подряд — наоборот, в реальных кейсах оцениваем качество тестов, фильтруем, где это нужно, и при необходимости корректируем результат.
Тогда почему вы выкидываете тесты по критерию "не увеличивает coverage" ? Если у вас идентифицирован корректный (ранее не тестированный) бизнес кейс - и он не увеличивает покрытие (например, вызывая все те же функции - но в другом порядке) ? А-а... нет, я знаю! Это такая корпоративная шизофрения: говорить правильные вещи, а делать все-равно то, за что дают плюшку по KPI... :-(
Это настоящее безумие. Вы отдаете самое главное - тесты, то есть доказательство корректности работы, тому (LLM) кто никакой ответственности за это не несет. Про отношение к метрике покрытия как к карго-культу уже хорошо сказано выше. Я полностью принимаю то, что ИИ напишет весь код чтобы он соответствовал тестам написанным людьми, но никак не наоборот.
На самом деле, есть два существенно разных сценария. Вариант 1: перед нами некое легаси, которое надо перетащить на новую версию фреймворка, или запихнуть в облако, или что-то там еще. Мы знаем что оно сейчас работает - это подтверждается практикой. Однако, как во всяком легаси - часть тестов сломана, часть закомментирована, и уже никто не знает почему. Если мы хотим прибить к столу текущий функционал и убедиться что мы его не сломаем в процессе миграции - наверное робот - лучший вариант. Приколотит так что потом зубами не оторвешь. :-)
Если же у нас Вариант 2: идет итерация разработки - то я с вами согласен: инструктировать LLM написать тест который "builds and passes" на непроверенный код - это только создавать себе иллюзию тестирования. Я так в одном проекте видел сервис с зелеными тестами, который в принципе не запускался (функции взаимодействия с БД дописать забыли - но с моками-то все было в порядке!)...
Так ведь можно и голову включать в процесс и тщательно проверять уже написанный тест, в том числе дорабатывая его. Все равно экономится время на создании основы. Глупый человек и так найдет где ошибиться, руками он тесты написал или нагенерировал. А человек более смышлёный не будет доверять сгенерированным тестам как есть, т.к. зелёный тест не гарантирует, что ничего не сломается.
Все собираюсь попробовать в работе TDD, где тесты пишет человек, а реализацию - машина
А почему вы считаете, что чтение и разбор кода после LLM займут сильно меньше времени, чем просто его реализация ? В современных фреймворках "тупая" часть тестирования (моки, ассерты) уже реализована: знай себе инициализируй объекты да проверяй результат... Еще раз - я не против ИИ помогающего писать тесты. Я против ИИ, которому ставят KPI по покрытию (и отбирают тесты целенаправленно на увеличение покрытия). Я (возможно с развитием ИИ это изменится) стою на том, что happy-path тесты должен писать разработчик (потому что ИИ понятия не имеет о бизнес-контексте). А вот анализ покрытия и идентификацию бизнес-кейсов которые не покрыты текущими тестами - вполне можно доверить ИИ. Но эти кейсы должен глазами посмотреть разработчик (т.е. они должны быть сгенерированы в человеко-читаемом виде!), возможно их отредактировать - и потом уже пусть ИИ их реализует (если может). А когда мы показываем человеку PR в котором уже сгенерирован десяток тестов - то или теперь ему придется восстанавливать по коду - какие бизнес-кейсы имелись в виду (и почему), или человек просто перекрестится и нажмет 'Approve' не вдаваясь в подробности...
Все собираюсь попробовать в работе TDD, где тесты пишет человек, а реализацию - машина
Пробовал, работает хорошо. При этом сначала прошу по требованиям к коду сгенерировать описания тестов, правлю, потом генерируется реализация тестов, потом реализация рабочего кода.
Почему-то меньше понравилось генерация описания тестов в стиле given-when-then, с более свободным описанием лучше работало. Может быть потому что я не умею BDD нормально готовить...
Это рутинный процесс, отнимающий много времени — когда задача уже выполнена, а в спринте еще пачка открытых тасок, редко кто хочет тратить время на юнит‑тесты, если код и так работает.
Пипец, ребята... Интересно, а как вы узнали, что ваш код работает?
писать их вручную — скучно, долго и не всегда хочется.
Да, работать вообще скучно... Но очень хорошо, что я не пользуюсь ОК.
Вы бы почитали что-нибудь про организацию разработки что ли. Присоединяюсь к предыдущим комментаторам на тему, что вы рискуете сделать себе хуже, вместо того, чтобы сделать лучше.
Генерация юнит-тестов с LLM: если бы посуда мылась сама