«Люди начинают пользоваться ИИ для написания QA-тестов. Это хорошо — но давайте разберемся.
Далее будут мои оценки качества LLM-генерированных тестов системы TestGen от Meta и ее первой реализации с открытым исходным кодом. Я могу в чем-то ошибаться. Аргументированная критика приветствуется.
Получил много реакций. Давайте углубимся в тему.
Почему люди пишут тесты?
Думаю, что большинство тестов сегодня пишут только потому, что кто-то сказал, что это нужно. Когда вы в последний раз видели, чтобы тесты поймали баг? А? Я имею в виду — до того, как баг попал на прод.
Контроль изменений в коде
Как я считаю, хорошее покрытие TypeScript-кода (и других ЯП со статической типизацией) устраняет потребность в большей части юнит-тестов. Типы «подскажут», когда неправильно применен метод или когда изменилось что-то затрагивающее другие точки приложения.
Однако исследования не подтверждают эффективность применения TypeScript, что касается предотвращения багов.
В «динамических» языках, таких как Python или Ruby, может понадобиться много юнит-тестов. Иначе нельзя проверить все экземпляры, которые нужно корректировать при переименовании функции или изменившихся аргументах.
Правило Бейонс
Правило Бейонс гласит: если вам что-то понравилось, нужно это протестировать.
Правило работает в больших компаниях с общим владением кодом, где каждый может менять код где угодно в любое время. Каждый может найти любой код, внести изменения, которые кажутся ему разумными, и поломать тесты.
Эти тесты сообщают программисту, что вы здесь предполагали странное поведение. Это заставляет обсудить ситуацию, и выяснить, нужно ли старое поведение и как инкорпорировать новое.
Заменитель общения в команде
Многие тесты, которые вы видите в природе, решают проблему коммуникации. Программисты трогают код, который они не понимают, программисты вызывают побочные эффекты в системах которыми они не владеют, или программисты вообще уходят и более недоступны.
Я предпочитаю решать эту проблему с помощью командной структуры. Дайте командам вертикальное право собственности на свои домены. Сохраняйте это право в течение длительного времени. Так у людей будет меньше причин копаться в коде, который они не понимают.
Вертикальное владение и вертикальная организация кода также означают, что у вас меньше шансов получить побочные эффекты, распространяющиеся на системы, которыми вы не владеете. Беспокойство о том, что изменение в модуле A приведет к поломке модуля D, скорее всего означает, что эти модули неправильно связаны между собой. Возможно, вы попали в классическую дилемму DRY vs SoC.
Заставить программистов думать
Это же хорошо. Попросить людей подумать о том, как они узнают, что код работает, — это фантастическое надувательство. Это заставляет их сперва думать о крайних случаях и возможных побочных эффектах, прежде чем писать код. Это точно работает, я проверял.
TDD хороший, но громоздкий подход. Писать пустые тест-кейсы — нормально.
Регрессионное
Да! Если вы напишете хорошие [интеграционные] тесты, то узнаете, когда что-то сломается после изменения кода. Фантастически удобно для рефакторинга и обновления библиотек.
Вы будете знать, что ваши тесты хороши, когда вам редко придется корректировать тесты, чтобы они соответствовали новому коду. Большинство юнит-тестов, которые я видел на проде, не соответствуют этому критерию; большинство интеграционных и сквозных тестов проходят.
ИИ может писать тесты, но
После всего этого вы считаете, что создание тестов на основе вашей имплементации — это ОК?
Вот пример из вчерашней ночи. Я игрался с Vitest, тестировал in-code вспомогательные утилиты, положился на Copilot.
Да, точно такой тест и я собирался написать. Он нормальный?
Не думаю. Смотрим. Код представляет собой базовое преобразование строк, его легко читать, легко понять, и вряд ли код изменится в будущем. Если мы вернемся к тесту чтобы внести изменения, то только когда изменится тестируемый API. В таком случае тесты будут так же бесполезны, как и код.
А поскольку ИИ взял тест из кода, вы даже не сможете применить правило Бейонсе. А что если преобразование строки неверно и программист не имел в виду именно это? Мы никогда не узнаем. Теперь ошибка у вас и в тесте, и в коде.
Высокоуровневые
Интеграционные или сквозные тесты, расположенные «выше по стеку», будут заметно полезнее. Например, когда пользователь нажимает на кнопку и вводит номер телефона, сработает ли поиск?
Этот тест не нужно менять, пока не изменится фича. Вы можете поменять всю реализацию под ней и сохранить тот же тест. Это ценный тест.
ИИ, пишущий подобные тесты — пока что фантастика.
Не беспокойтесь о покрытии кода. Сосредоточьтесь на покрытии функций.
Какие тесты мог бы писать ИИ: три примера
3 идеи по применению ИИ для написания тестов, которые могли бы сработать. Я еще не пробовал.
- Для fuzz-тестирования. Генерировать множество похожих на настоящие исходных данных, чтобы обнаруживать крайние случаи.
- Для преобразования критериев приемки в тесты. Вы пишете пункты > ИИ пишет высокоуровневые тесты > вы пишете код.
- Для написания кода, который соответствует вашим тестам (то есть тот же TDD). Вы пишете тесты и позволяете ИИ разбираться со всем остальным. Это было бы круто, но тяжело для нашего самолюбия.»
