Как LLM навсегда изменили тестирование

Если вы читали хотя бы одну статью про тестирование IT-продуктов, то наверняка где-то близко к началу была фраза вроде: «Пишите поведенческие тесты».

Возможно, вы даже слышали золотое: «Write tests. Not too many. Mostly integration». Как же эта фраза переворачивала мировоззрение разработчиков всего пару лет назад! 🥹

Как у нас обстоят дела с тестами сейчас? LLM пишут тесты (отлично!). Они пишут много тестов, очень много тестов (так, кажется, начинаются проблемки). Многие тесты проверяют детали реализации вместо поведения (пу-пу-пу, приехали).

Получается, что LLM сломали тестирование? Нам, наверное, нужно заставить их писать хорошие тесты, да? Придумать правила там, ограничения, статических проверок навалить, всё такое? Не смейте. Вы сделаете только хуже.

Я ярый фанат тестов. Они спасали мой зад не одну сотню раз. И я шарю за best practices тестирования. Помимо этого, я неоднократно наблюдал, как тестирование деталей реализации мало того, что снижало доверие к тестам, так ещё и поселяло в головах разработчиков мысли вроде: «Ой, наверное, опять ложное срабатывание». После десятка таких вот «ложных срабатываний» они начинали писать меньше тестов, потихоньку теряяя доверие к ним. А уже после сотни не видели в них смысла и переставали писать вовсе. А зачем, если поддержка сложная, а выхлопа нет?

Ну, значит, всё-таки ограничиваем LLM? Нет.

У LLM есть одна особенность: они не страдают от нашей слабости «наверное, опять ложное срабатывание». Даже если LLM посчитает, что тест «просто не проходит», то в большинстве случаев она оставит этот тест и скажет вам, что он падает. Так что если ваша LLM хочет протестировать, насколько пикселей скруглен элемент, — пускай дерзает! Если ей вдруг приспичит обратиться к элементу по классу — разрешите! Она решила протестировать сценарии, которые вы не планировали покрывать тестами? Вам же лучше!

Так в чём польза? Дело в том, что тесты деталей реализации помогают LLM. Она запустит их, увидит, что они падают, и пойдёт разбираться почему. Если она поймёт, что это сделано по запросу пользователя, то изменит или удалит тест, а если нет — исправит код.

То есть то, что для нас зло, что делает наши продукты хуже, для LLM — мёд. Для неё это ещё одна возможность проверить себя, убедиться, что она нигде не напортачила. И эта проверка может стать решающей.

Пример из жизни: я по роду деятельности в основном занимаюсь интерфейсами, и LLM любят проявлять свои дизайнерские качества в неожиданных местах. Где-то скругление уберут, где-то отступ поправят, а где-то цвет заменят. Так вот, чтобы они таким не занимались, я тестирую все стили через юнит-тесты. Таким образом, нужные мне значения фиксируются в «памяти» модели, и даже если она случайно их изменит, то тесты скажут: «no, no, no, мистер LLM, ты не будешь ломать интерфейс, верни всё как было».

Вы скажете: «А как же скриншотные тесты?». На что я отвечу, что это не панацея. Они тоже нужны, но уже для нас. Для LLM они не помощник: слишком долго дожидаться результата, а даже если модель дождётся, то на чтение скриншотов уйдёт весь контекст (я проверял). При этом скриншотные тесты не теряют своей пользы — мы всё также можем убедиться, что с интерфейсом всё в порядке своей парой глаз.

Ну и вообще, не боритесь с LLM. Бороться с LLM — изначально глупая затея. Вы поставите ей правило, она придумает, как его обойти; вы улучшите правило, она придумает, как его перепрыгнуть; вы сделаете правило пуленепробиваемым, она принесёт динамит. Это как биться головой об стену — рано или поздно стена победит.

Примите правила игры. Перестаньте ограничивать LLM. Направляйте её.

Объясните ей, что такое поведенческие тесты, и скажите, чтобы она их писала. Настройте TDD-воркфлоу, чтобы ни один багфикс, ни одна фича не остались без тестов. Настройте линтинг, чтобы он проверял, что написанные тесты на самом деле что-то тестируют. На этом всё.

Дальше пусть разбирается сама — написала фигню? Её искусственной голове болеть по этому поводу. Ваша реальная голова только выиграет от ещё одной проверки.