Мои заметки на разные темы, уровень - "для продолжающих"
Vibe Coding -> AI SWE, AI Coding Tools, Agents, news, links
Чат (!!!): https://t.me/+B1fB3sZbaVthMDhi
Админ @deksden
В канал бесплатно публикую опенсорс проекты - пишите админу
Вакансии? админу
Post #286
461
Тестирование, бизнес-процессы
Я уже затрагивал эту тему ранее, в канале, в лонгриде про тестирование : https://t.me/deksden_notes/249
▶️ Сейчас хотел сказать про немного другой аспект той же проблемы.
Когда я делаю какие то системы, я прежде всего на любую фичу планирую какой то интеграционный тест. По мне елать агентами какую то фичу без такого теста - штука бесмысленная! Даже если сделать все юнит тесты, проработать их стратегию тестирования отдельно, даже если сделать полуинтеграционные тесты, и интеграционыне, все равно могут получаться неработающие системы
ℹ️ Напомню применяемую мною иерархию тестирования:
- юнит тесты: тестируют базовую логику модулей в изоляции; все зависимости обязательно мокнуты, то есть демонстрируют строго детерминированное поведение;
- полу-интеграционные тесты: когда части системы тестируются во взаимодействии с другими, но другие части могут быть частично моками или стабами;
- компонентные тесты: когда в UI есть что то сложное, и его надо отдельно протестировать на правильность поведения;
- тесты - сценарии: по сути большие интеграционные тесты, бизнес-процессы; когда система работает в приближенном к боевому состоянию и тестируется именно полнофункциональная работа по какому то пользовательскому сценарию с реальными компонентами.
👉 Основной поинт этого поста: главным для меня является интеграционный тест / бизнес-процесс. Без него совсем нельзя в AI SWE. Можно без юнит тестов, без компонентных и полу-интеграционных. Они просто подтягивают качество элементов системы. Но основным способом проверять функционирование системы я вижу только бизнес-процесс, без него из элементов может система то и не сложится. "Угадал все буквы но не смог назвать слово!"
❓ Зачем тогда другие тесты? Потому что без них бывает довести интеграционный тест до зеленого состояния совсем затруднительно - слишком много проблем в элементах, из которых состоит система. Если в каждом из них есть "люфт", то система может стать практически неработоспособной - будет все время "виляться" во многих местах, и стабилизировать будет сложно.
Поэтому качество системы подтягиваем на всех возможных уровнях: начиная с lint, продолжаем юнит тестами и полу-интеграционными/компонентными.
❓Что за сценарии? Это практически те же юзкейсы из фич/эпиков аджайла. То есть "хотелка" про то, как пользователь работает в системе, только переведенная в "автоматический" режим.
👉 А вот второй поинт поста: для запуска таких тяжелых сценариев я всегда делаю агентное воркфлоу. Подход такой: я делаю некую инструкцию для ИИ агента:
- как пересобрать систему (потому что часто тест гоняется после проведенной доработки, и нужно собрать систему чтобы подтянуть изменения),
- как поднимать систему в тестовом состоянии (если у вас 3-5 компонентов, то это тоже уже процесс),
- как запустить тестовый сценарий (каким раннером)
- какие ключевые метрики мы ожидаем (если сценарий оформлен как тест в некоем раннере, то тут просто - тест зеленый);
- иногда бывает что этот сценарий - это не тест, а полностью агентный воркфлоу, когда агент чего то запускает, чего то делает, и контролирует результат; по сути - тот же тест, но в виде агентного воркфлоу;
- как интерпретирвоать результаты - чтобы агент понимал критерии успеха и неуспеха,
- как фиксировать отклонения: какую информацию и где собирать если есть отклонение (в каких логах покопаться, откуда их вытаскивать, может быть в БД сходить или в хранилище и исследовать артефакты);
- где лежат фикстуры процесса: тестовые наборы данных (файлы примеров, сиды БД, ...).
Идеальный вариант - писать интеграционный тест с агентом, чтобы он сам прокликал ui и сделал этот сценарий в playwright. Антигравити с браузером как раз для таких штук и будут оптимальна!
▶️ Вы верно увидели сходство: по сути, я оформляю СКИЛЛ для запуска этого бизнес-процесса.
👉 Когда кодекс запустит скиллы, придет пора оформить это в виде реального скилла, раз этот формат прижился!
👌 И - да, тесты вполне может гонять зайка, что дешево, шустро и в качественной упряжке.
А вы гоняете тесты под агентами?
Telegram DEKSDEN notes Тестирование в эпоху AI агентов ч1/3
Попробую изложить имеющиеся соображения по тестированию и подходов к нему в некотором преломлении к агентам. Может быть покапитанствую местами - но куда ж без этого)
Сначала о термине "тестирование". Это огромная тема… Я уже затрагивал эту тему ранее, в канале, в лонгриде про тестирование : https://t.me/deksden_notes/249
▶️ Сейчас хотел сказать про немного другой аспект той же проблемы.
Когда я делаю какие то системы, я прежде всего на любую фичу планирую какой то интеграционный тест. По мне елать агентами какую то фичу без такого теста - штука бесмысленная! Даже если сделать все юнит тесты, проработать их стратегию тестирования отдельно, даже если сделать полуинтеграционные тесты, и интеграционыне, все равно могут получаться неработающие системы
ℹ️ Напомню применяемую мною иерархию тестирования:
- юнит тесты: тестируют базовую логику модулей в изоляции; все зависимости обязательно мокнуты, то есть демонстрируют строго детерминированное поведение;
- полу-интеграционные тесты: когда части системы тестируются во взаимодействии с другими, но другие части могут быть частично моками или стабами;
- компонентные тесты: когда в UI есть что то сложное, и его надо отдельно протестировать на правильность поведения;
- тесты - сценарии: по сути большие интеграционные тесты, бизнес-процессы; когда система работает в приближенном к боевому состоянию и тестируется именно полнофункциональная работа по какому то пользовательскому сценарию с реальными компонентами.
👉 Основной поинт этого поста: главным для меня является интеграционный тест / бизнес-процесс. Без него совсем нельзя в AI SWE. Можно без юнит тестов, без компонентных и полу-интеграционных. Они просто подтягивают качество элементов системы. Но основным способом проверять функционирование системы я вижу только бизнес-процесс, без него из элементов может система то и не сложится. "Угадал все буквы но не смог назвать слово!"
❓ Зачем тогда другие тесты? Потому что без них бывает довести интеграционный тест до зеленого состояния совсем затруднительно - слишком много проблем в элементах, из которых состоит система. Если в каждом из них есть "люфт", то система может стать практически неработоспособной - будет все время "виляться" во многих местах, и стабилизировать будет сложно.
Поэтому качество системы подтягиваем на всех возможных уровнях: начиная с lint, продолжаем юнит тестами и полу-интеграционными/компонентными.
❓Что за сценарии? Это практически те же юзкейсы из фич/эпиков аджайла. То есть "хотелка" про то, как пользователь работает в системе, только переведенная в "автоматический" режим.
👉 А вот второй поинт поста: для запуска таких тяжелых сценариев я всегда делаю агентное воркфлоу. Подход такой: я делаю некую инструкцию для ИИ агента:
- как пересобрать систему (потому что часто тест гоняется после проведенной доработки, и нужно собрать систему чтобы подтянуть изменения),
- как поднимать систему в тестовом состоянии (если у вас 3-5 компонентов, то это тоже уже процесс),
- как запустить тестовый сценарий (каким раннером)
- какие ключевые метрики мы ожидаем (если сценарий оформлен как тест в некоем раннере, то тут просто - тест зеленый);
- иногда бывает что этот сценарий - это не тест, а полностью агентный воркфлоу, когда агент чего то запускает, чего то делает, и контролирует результат; по сути - тот же тест, но в виде агентного воркфлоу;
- как интерпретирвоать результаты - чтобы агент понимал критерии успеха и неуспеха,
- как фиксировать отклонения: какую информацию и где собирать если есть отклонение (в каких логах покопаться, откуда их вытаскивать, может быть в БД сходить или в хранилище и исследовать артефакты);
- где лежат фикстуры процесса: тестовые наборы данных (файлы примеров, сиды БД, ...).
Идеальный вариант - писать интеграционный тест с агентом, чтобы он сам прокликал ui и сделал этот сценарий в playwright. Антигравити с браузером как раз для таких штук и будут оптимальна!
▶️ Вы верно увидели сходство: по сути, я оформляю СКИЛЛ для запуска этого бизнес-процесса.
👉 Когда кодекс запустит скиллы, придет пора оформить это в виде реального скилла, раз этот формат прижился!
👌 И - да, тесты вполне может гонять зайка, что дешево, шустро и в качественной упряжке.
А вы гоняете тесты под агентами?
- 👍 5
- ❤🔥 3
- 🔥 3
