Тестирование, бизнес-процессы


Я уже затрагивал эту тему ранее, в канале, в лонгриде про тестирование : https://t.me/deksden_notes/249

▶️ Сейчас хотел сказать про немного другой аспект той же проблемы.

Когда я делаю какие то системы, я прежде всего на любую фичу планирую какой то интеграционный тест. По мне елать агентами какую то фичу без такого теста - штука бесмысленная! Даже если сделать все юнит тесты, проработать их стратегию тестирования отдельно, даже если сделать полуинтеграционные тесты, и интеграционыне, все равно могут получаться неработающие системы

ℹ️ Напомню применяемую мною иерархию тестирования:

- юнит тесты: тестируют базовую логику модулей в изоляции; все зависимости обязательно мокнуты, то есть демонстрируют строго детерминированное поведение;

- полу-интеграционные тесты: когда части системы тестируются во взаимодействии с другими, но другие части могут быть частично моками или стабами;

- компонентные тесты: когда в UI есть что то сложное, и его надо отдельно протестировать на правильность поведения;

- тесты - сценарии: по сути большие интеграционные тесты, бизнес-процессы; когда система работает в приближенном к боевому состоянию и тестируется именно полнофункциональная работа по какому то пользовательскому сценарию с реальными компонентами.


👉 Основной поинт этого поста: главным для меня является интеграционный тест / бизнес-процесс. Без него совсем нельзя в AI SWE. Можно без юнит тестов, без компонентных и полу-интеграционных. Они просто подтягивают качество элементов системы. Но основным способом проверять функционирование системы я вижу только бизнес-процесс, без него из элементов может система то и не сложится. "Угадал все буквы но не смог назвать слово!"

❓ Зачем тогда другие тесты? Потому что без них бывает довести интеграционный тест до зеленого состояния совсем затруднительно - слишком много проблем в элементах, из которых состоит система. Если в каждом из них есть "люфт", то система может стать практически неработоспособной - будет все время "виляться" во многих местах, и стабилизировать будет сложно.

Поэтому качество системы подтягиваем на всех возможных уровнях: начиная с lint, продолжаем юнит тестами и полу-интеграционными/компонентными.

❓Что за сценарии? Это практически те же юзкейсы из фич/эпиков аджайла. То есть "хотелка" про то, как пользователь работает в системе, только переведенная в "автоматический" режим.

👉 А вот второй поинт поста: для запуска таких тяжелых сценариев я всегда делаю агентное воркфлоу. Подход такой: я делаю некую инструкцию для ИИ агента:
- как пересобрать систему (потому что часто тест гоняется после проведенной доработки, и нужно собрать систему чтобы подтянуть изменения),
- как поднимать систему в тестовом состоянии (если у вас 3-5 компонентов, то это тоже уже процесс),
- как запустить тестовый сценарий (каким раннером)
- какие ключевые метрики мы ожидаем (если сценарий оформлен как тест в некоем раннере, то тут просто - тест зеленый);
- иногда бывает что этот сценарий - это не тест, а полностью агентный воркфлоу, когда агент чего то запускает, чего то делает, и контролирует результат; по сути - тот же тест, но в виде агентного воркфлоу;
- как интерпретирвоать результаты - чтобы агент понимал критерии успеха и неуспеха,
- как фиксировать отклонения: какую информацию и где собирать если есть отклонение (в каких логах покопаться, откуда их вытаскивать, может быть в БД сходить или в хранилище и исследовать артефакты);
- где лежат фикстуры процесса: тестовые наборы данных (файлы примеров, сиды БД, ...).


Идеальный вариант - писать интеграционный тест с агентом, чтобы он сам прокликал ui и сделал этот сценарий в playwright. Антигравити с браузером как раз для таких штук и будут оптимальна!


▶️ Вы верно увидели сходство: по сути, я оформляю СКИЛЛ для запуска этого бизнес-процесса.

👉 Когда кодекс запустит скиллы, придет пора оформить это в виде реального скилла, раз этот формат прижился!

👌 И - да, тесты вполне может гонять зайка, что дешево, шустро и в качественной упряжке.

А вы гоняете тесты под агентами?