На прошедшей неделе сильно больше обычного программировал. На работе есть небольшой сайд проект – консольное Kotlin приложение для экспорта дизайн-системы из фигмы, запускаемое на CI, которое я в одно лицо время от времени поддерживаю. Вот в нём и программировал. И так как я возвращаюсь в него не очень часто – сам забываю какая хитрая логика обхода по нодам там написана, не говоря даже о том, что там всегда были и будут какие-то костыльки, которые обходят несовершенство дизайнерской фигмы.
Но вообще я не об этом. Я к тому, что раз в несколько месяцев от дизайнеров накапливаются какие-то ломающие изменения или добавляется что-то новое. Туда нужно залезть, что-то доработать, и это делать страшно, ведь сломать проще простого. Особенно учитывая то, что в последнее время я там всё вайбкодю. Это точка, в которой я понимаю, что мне нужны тесты. Честно говоря, даже в основном проекте так не нужны, там всегда есть несколько десятков людей, которые так или иначе в нём варятся и могут проконтролировать. Хорошо это или плохо, кстати, это вопрос. Но точно вызывает привыкание.
Соответственно решил совместить полезное с приятным, поэтому вооружился агентом и пошёл покрывать его тестами. Не только как самоцель, но и опыт AI тестов пережить и отрефлексировать, чтобы перетащить его на большой проект. И вот что я понял. Мысли довольно предсказуемые, но в смысле написания тестов я совсем самоучка, до меня многие вещи долго доходят. 🤔
Как и с любым другим кодом агент пишет фигово, если ему не очертить рамки. Про это я уже много раз рассказывал, документация "как писать тесты" это абсолютно мастхэв. Фреймворк, подходы, примеры, стиль, на что обращать внимание, на что нет.
Если подойти к этой задаче наивно и попросить написать его тесты на какой-то твой существующий класс/функцию, то на выходе там мок на моках и моками погоняют. И в некоторых кейсах тест кода вообще превращается в бессмысленный тест моков, не говоря уж о том, что моки сами по себе довольно хрупки и неприятно ломаются. Кмк, если есть вариант написать фейк реализацию, то это почти всегда чище. Не отрицаю, что моки иногда нужны, но их тоже нужно уметь использовать, а не лепить везде, как изначально хочется.
Самое прикольное, кстати, в том, что с людьми абсолютно тоже самое. Если среднего разраба не обучая хорошим практикам втупую попросить покрыть его код тестами, то получится такая же ерунда.
Поэтому большая часть работы здесь заключалась в том, что я в процессе рефакторил сам исходный код, чтобы на это можно было написать хорошие тесты. Инвертировать зависимости, абстрагировать незначащий для тестов код за интерфейсами, вот это всё. Естественно, я делал это тоже не сам, а с ногами на столе и руками за головой наговаривал через superwhisper поток мыслей агенту. Время от время код правил, конечно, но в целом это работает. 🤟
А вот сами тесты после рефакторинга кода у меня вообще с первого раза залетали в таком качестве, что я там ни единой строчки не написал руками за всё время. На несколько тысяч строк "продакшн" кода в тестах получилось даже побольше. Покрытие в ключевых местах взлетело и я вообще с кайфом дописал клодом пару новых фич.
Выводы какие. Думать всё ещё надо. У тебя в голове или в написанной кем-то документации должно быть представление о прекрасном, которое будет транслироваться нейронкам. Если представление о прекрасном есть, это уже работает офигенно. Но натренировать в себе представление о прекрасном это та ещё задачка.