"Тестирование, бизнес-процессы Я уже затрагивал эту тему ранее, в канале, в лонгриде про тестирование : https://t.me/deksden_notes/249 ▶️ Сейчас хотел сказать про немного другой аспект той же проблемы. Когда я делаю какие то системы, я прежде всего на любую фичу планирую какой то интеграционный тест. По мне елать агентами какую то фичу без такого теста - штука бесмысленная! Даже если сделать все юнит тесты, проработать их стратегию тестирования отдельно, даже если сделать полуинтеграционные тесты, и интеграционыне, все равно могут получаться неработающие системы ℹ️ Напомню применяемую мною иерархию тестирования: - юнит тесты: тестируют базовую логику модулей в изоляции; все зависимости обязательно мокнуты, то есть демонстрируют строго детерминированное поведение; - полу-интеграционные тесты: когда части системы тестируются во взаимодействии с другими, но другие части могут быть частично моками или стабами; - компонентные тесты: когда в UI есть что то сложное, и его надо отдельно протестировать на правильность поведения; - тесты - сценарии: по сути большие интеграционные тесты, бизнес-процессы; когда система работает в приближенном к боевому состоянию и тестируется именно полнофункциональная работа по какому то пользовательскому сценарию с реальными компонентами. 👉 Основной поинт этого поста: главным для меня является интеграционный тест / бизнес-процесс. Без него совсем нельзя в AI SWE. Можно без юнит тестов, без компонентных и полу-интеграционных. Они просто подтягивают качество элементов системы. Но основным способом проверять функционирование системы я вижу только бизнес-процесс, без него из элементов может система то и не сложится. ""Угадал все буквы но не смог назвать слово!"" ❓ Зачем тогда другие тесты? Потому что без них бывает довести интеграционный тест до зеленого состояния совсем затруднительно - слишком много проблем в элементах, из которых состоит система. Если в каждом из них есть ""люфт"", то система может стать практически неработоспособной - будет все время ""виляться"" во многих местах, и стабилизировать будет сложно. Поэтому качество системы подтягиваем на всех возможных уровнях: начиная с lint, продолжаем юнит тестами и полу-интеграционными/компонентными. ❓Что за сценарии? Это практически те же юзкейсы из фич/эпиков аджайла. То есть ""хотелка"" про то, как пользователь работает в системе, только переведенная в ""автоматический"" режим. 👉 А вот второй поинт поста: для запуска таких тяжелых сценариев я всегда делаю агентное воркфлоу. Подход такой: я делаю некую инструкцию для ИИ агента: - как пересобрать систему (потому что часто тест гоняется после проведенной доработки, и нужно собрать систему чтобы подтянуть изменения), - как поднимать систему в тестовом состоянии (если у вас 3-5 компонентов, то это тоже уже процесс), - как запустить тестовый сценарий (каким раннером) - какие ключевые метрики мы ожидаем (если сценарий оформлен как тест в некоем раннере, то тут просто - тест зеленый); - иногда бывает что этот сценарий - это не тест, а полностью агентный воркфлоу, когда агент чего то запускает, чего то делает, и контролирует результат; по сути - тот же тест, но в виде агентного воркфлоу; - как интерпретирвоать результаты - чтобы агент понимал критерии успеха и неуспеха, - как фиксировать отклонения: какую информацию и где собирать если есть отклонение (в каких логах покопаться, откуда их вытаскивать, может быть в БД сходить или в хранилище и исследовать артефакты); - где лежат фикстуры процесса: тестовые наборы данных (файлы примеров, сиды БД, ...). Идеальный вариант - писать интеграционный тест с агентом, чтобы он сам прокликал ui и сделал этот сценарий в playwright. Антигравити с браузером как раз для таких штук и будут оптимальна! ▶️ Вы верно увидели сходство: по сути, я оформляю СКИЛЛ для запуска этого бизнес-процесса. 👉 Когда кодекс запустит скиллы, придет пора оформить это в виде реального скилла, раз этот формат прижился! 👌 И - да, тесты вполне может гонять зайка, что дешево, шустро и в качественной упряжке. А вы гоняете тесты под агентами?"