Что нужно знать бизнесу о современной ИИ-разработке и тестировании

Я видел много раз, как бизнес пытался вайбкодить сам или нанимал вчерашних студентов без опыта реального программировани и проектирования для написания приложений дёшево и быстро. Что может пойти нетак? Больше не надо знать программирование - говоришь на своёём языке, ИИ тебе всё пишет, можно даже попросить его покрыть текстами и сделать всё в лучших практиках архитектуры... Так ведь? Или нет? =) Те, кто писал что-то по сложнее мини-парсера или простенькие интеграции (которые вообще можно найти бесплатно и не пистаь) - понимают, что халява заканчивается быстро. Как только база кода вырастает, ИИ начинает галюцинировать, дублировать код, создавать бредовые бизнес-процессы, путаться, и чем больше ты пишешь ему "нет, сделай нормально, сделай хорошо", тем хуже он делает. Знакомо? Обсудим, как писать код быстрее и дешевле, но при этом минимизировать количество седых волос, мертвых нейронов и дофаминовых ям.

Как правильно писать тесты для Codex, Claude и других современных агентов

Статья от команды Ingello Systems

Современная разработка изменилась радикально. Еще вчера бизнес жил в мире, где код писали люди, тесты писали люди, баги тоже были человеческие, местами ленивые, местами талантливые. Сегодня у нас в команде появились AI-агенты: Codex, Claude и другие системы, которые умеют генерировать код, править архитектуру, запускать тесты, писать pull request и с очень уверенным лицом говорить: все готово =)

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

Для бизнеса это уже не техническая мелочь, а вопрос денег, сроков и устойчивости процессов. По материалам DORA 2024, AI уже массово вошел в ежедневную практику разработки. Playwright, Pact, Temporal, OpenTelemetry, Prometheus, OpenAI Developers и Anthropic Engineering в разных формах говорят об одном и том же: если система стала сложнее и более автоматизированной, то тестирование должно стать не формальностью, а отдельной инженерной дисциплиной.

Именно поэтому вопрос как писать тесты для современных AI-агентов сегодня критичен для бизнеса. Особенно если речь идет не о лендинге на три кнопки, а о реальных системах с интеграциями, очередями, скрапингом, голосовыми потоками, Telegram-ботами, webhooks, AI-модулями и сложной инфраструктурой.

В Ingello Systems мы проектируем и разрабатываем как корпоративные системы, так и стартап-продукты. Поэтому дальше я разберу тему не в стиле абстрактной теории, а на живых классах приложений, с которыми бизнес сталкивается каждый день.

Почему тестирование сегодня важно не только разработчику, но и директору, владельцу и инвестору

Если говорить совсем по-честному, бизнесу вообще не интересно количество тестов. Бизнесу интересно другое:

• не теряются ли деньги
• не ломаются ли процессы после релиза
• не стоит ли команда на паузе из-за регрессии
• не превращается ли каждая доработка в маленькую гражданскую войну
• можно ли выпускать изменения быстро и без страха
• можно ли доверить часть работы AI-агентам без ощущения, что вы посадили стажера управлять атомной электростанцией

Когда у компании нет нормальной стратегии тестирования, разработка начинает напоминать старый склад, где коробки сложены до потолка, лампочка мигает, а кто-то уверяет, что система учета почти работает. Формально все стоит на месте. По факту — любое движение может вызвать лавину.

Для стартапа отсутствие тестов означает, что MVP нельзя нормально доращивать. Для корпоративной системы это еще опаснее: сбой начинает бить не по красивому интерфейсу, а по реальным операциям, логистике, складу, финансам, документообороту, врачам, менеджерам, поддержке и руководителям.

Мы видели это в разных проектах. Например, в Prime EVA и GadFul цена ошибки в учете и интеграциях очень далека от академической. В Svit BUS или LEX ошибка в маршрутах, бронировании, оплате или возвратах бьет по деньгам и доверию пользователей. В Evrika, Lita и L-Doc качество тестирования уже упирается не просто в удобство, а в надежность процессов и данных.

Главная мысль: тестировать нужно не код как текст, а риск как событие

Вот это место стоит запомнить.

Хороший тест проверяет не то, что функция вызвалась, а то, что бизнес-риск контролируется.

Например:

• не просто проверить, что отправился HTTP-запрос
• а проверить, что заказ действительно не дублируется при повторной доставке webhook
• не просто проверить, что парсер вернул массив
• а проверить, что новая запись на странице обнаруживается один раз и попадает в базу данных без дублей
• не просто проверить, что Telegram API ответил 200
• а проверить, что пользователь получил правильное уведомление и система не отправила его трижды
• не просто проверить, что AI вернул текст
• а проверить, что текст соответствует требованиям задачи, не ломает workflow и не сжигает бюджет вхолостую

Это очень важный сдвиг в мышлении. Особенно когда тесты пишет агент. Потому что AI очень любит делать то, что легко автоматизируется, а не то, что реально важно.

Почему Codex и Claude часто пишут тесты, которые выглядят умно, но не имеют смысла

Потому что агент по умолчанию оптимизируется под локальную задачу: сгенерировать что-то похожее на хороший тест. А не под ваш конкретный бизнес-риск.

Поэтому без нормальных рамок он часто делает следующее:

• тестирует внутренние детали реализации, а не поведение системы
• мокает вообще все подряд и получает зеленую, но фальшивую картину мира
• пишет слишком дорогие end-to-end тесты там, где нужен был один быстрый unit test
• создает снепшоты огромных структур, которые никто потом не читает
• дублирует одну и ту же проверку на нескольких слоях
• делает нестабильные тесты, которые нельзя запускать на каждом PR
• не маркирует платные AI-evals отдельно от обычных regression-тестов

В итоге у команды появляется не система качества, а театральная декорация тестирования. Все серьезно, все мигает, CI шумит, а уверенности нет.

Какая методология тестирования нужна современным приложениям

Обычной пирамиды тестирования уже недостаточно, хотя сама идея по-прежнему полезна. Для современных систем мы в Ingello Systems обычно используем более взрослую модель: портфель проверок.

То есть мы заранее понимаем, какие слои риска есть в продукте, и под каждый слой строим свой тип тестов.

1. Детерминированные доменные тесты

Это правила, формулы, статусы, переходы состояний, дедупликация, ограничения, права доступа, маппинги, вычисления. Все, что должно быть предсказуемо.

2. Компонентные и интеграционные тесты

Проверяют работу с базой, файлами, очередями, брокерами сообщений, кешем, HTTP-клиентами, внешними API, локальными контейнерами.

3. Контрактные тесты

Фиксируют, как именно ваш сервис ожидает общаться с внешней системой. Что должен содержать запрос, какой shape ответа допустим, что делать при изменении схемы.

4. Сценарные и end-to-end тесты

Проверяют несколько ключевых пользовательских или бизнес-сценариев от начала до конца. Их должно быть мало. Иначе вы не тестируете систему, а пытаетесь зацементировать весь мир.

5. Runtime-проверки

Это не совсем классические тесты, но без них в современной системе никуда. Synthetic checks, canary, health endpoints, monitoring, tracing, alerting. То есть проверка того, что система не только собирается, но и живет.

6. AI evals и agent evals

Если в продукте есть LLM, генерация текста, ассистенты, пайплайны принятия решений или автономные агенты, их нельзя тестировать как обычные функции. Для них нужна отдельная система оценивания.

Как выбирать, какие тесты запускать всегда, а какие только иногда

Вы очень правильно подметили, что запускать все тесты каждый раз бессмысленно. Это одна из самых частых ошибок молодых процессов. Не всякий тест должен жить в одном и том же контуре.

Нормальная стратегия выглядит примерно так.

На каждом коммите или локально перед push

• линтеры
• type checking
• быстрые unit-тесты
• часть component tests без сети
• тесты на критичные доменные инварианты

Это должно быть быстро. Если здесь все длится вечность, команда начнет обходить правила. А если правила постоянно обходят, то это уже не процесс, а декоративная вывеска.

На pull request

• все быстрые тесты
• измененные component/integration tests
• контрактные тесты
• небольшой набор критичных e2e-сценариев

Ночью или по расписанию

• медленные end-to-end тесты
• sandbox-тесты внешних интеграций
• нагрузочные мини-прогоны
• платные AI-evals
• дрейф-проверки скраперов и парсеров

Перед релизом

• smoke на staging
• миграции
• регрессионный набор по критичному бизнес-контуру
• проверка очередей, cron, webhook endpoints, внешних callback

После релиза

• production smoke
• canary
• метрики ошибок
• алерты на аномалии
• synthetic journey по ключевым действиям

Главная идея: у тестов должен быть контекст запуска. Одни защищают скорость. Другие защищают интеграции. Третьи защищают релиз. Четвертые защищают production.

Как писать тесты для обычных алгоритмических приложений

Это самый понятный класс задач. Здесь мир еще более-менее честный: входы, выходы, правила, статусы, вычисления.

Такие системы встречаются в CRM, ERP, WMS, логистике, бронировании, учете, продажах, документообороте, финоперациях. У нас в кейсах это, например, platFORMA, FORMA CRM, FORMA WMS, FORMA BPM, NorthWest, Taxer.

Что здесь тестировать в первую очередь

• golden cases — эталонные сценарии с заранее известным правильным результатом
• boundary cases — пустые, крайние, нулевые, отрицательные значения, таймзоны, переходы дат, валюты, округления
• инварианты — свойства, которые должны сохраняться всегда
• property-based tests — генерация большого количества входных данных и проверка общих свойств
• переходы состояний — что можно и нельзя делать из конкретного статуса

Какие инварианты полезны бизнесу

• сумма заказа не может стать отрицательной
• два раза примененный один и тот же webhook не должен удвоить операцию
• отмена заказа не должна создавать новый платеж
• остатки на складе должны сходиться с журналом движений
• скидка не должна увеличивать цену
• пользователь без нужной роли не должен видеть закрытый контур данных

Для агентов типа Codex это хороший слой. Но агенту нельзя просто говорить напиши тесты на сервис. Ему нужно давать инженерное ТЗ:

• какие бизнес-правила есть
• какие инварианты критичны
• какие edge cases обязательны
• какие тесты должны быть быстрыми
• какие зависимости запрещено мокать

Иначе агент напишет что-то формально осмысленное, но практически декоративное.

Как тестировать приложения с интеграциями

Современная система почти никогда не живет одна. Там платежи, CRM, ERP, email-провайдер, SMS, карты, analytics, S3-совместимое хранилище, внешние каталоги, ERP клиента, API партнеров, внешние кабинеты, агрегаторы и еще десяток друзей, которым нельзя полностью доверять.

В таких системах основная мысль очень простая: вы тестируете не чужой сервис, а свой контракт с ним.

Хорошая стратегия для внешней интеграции

• быстрые тесты на сериализацию и маппинг
• контрактные тесты на формат запросов и ответов
• обработка ошибок, таймаутов, повторов, частичных отказов
• sandbox-прогоны по расписанию
• production monitoring и алерты

Что особенно важно проверить

• что будет, если внешний сервис вернет поле другого типа
• что будет, если в ответе не хватит нужного поля
• что будет, если появятся новые поля
• что будет, если ответ придет с задержкой
• что будет, если событие придет повторно
• что будет, если события придут не в том порядке
• как обрабатываются rate limits

В проектах вроде Prime EVA, Vorfahr, NaturalTTS, GadFul и City Ingello интеграции — это уже не аксессуар, а часть скелета системы. Там ошибка на границе сервисов быстро превращается в цепочку побочных эффектов.

Как тестировать скрапинг и парсинг

Скрапинг и парсинг — прекрасный пример того, как naive-подход ломает инженерную психику. Если тестировать такую систему одним большим e2e через живой интернет, то она будет то работать, то не работать, то зависеть от времени суток, то от настроения чужого сайта. Красота дикая, надежность сельская.

Правильнее разделить задачу на слои.

Слой 1. Fetcher

Как именно мы получаем страницу. Что делаем с 403, 404, 429, redirect, broken SSL, timeout, anti-bot защитой.

Слой 2. Parser

Как мы извлекаем сущности из HTML, XML, JSON, feed, sitemap или другого формата.

Слой 3. Normalizer

Как приводим данные к единой форме: даты, валюты, имена, ссылки, идентификаторы.

Слой 4. Dedupe

Как понимаем, что это новая запись, а не старая запись в другом платье.

Слой 5. Writer

Как сохраняем результат в базу данных и какие side effects запускаем.

Слой 6. Scheduler

Когда и как часто система вообще делает повторную проверку.

Какие тесты тут нужны

• фикстуры с реальными HTML-страницами и их версиями
• узкие parser tests на локальных файлах
• тесты на обнаружение новой записи
• тесты на дедупликацию
• тесты на корректную нормализацию дат, цен, ссылок
• тесты на scheduler с fake clock
• один-два canary-прогона на реальном источнике по расписанию

Очень полезная практика — хранить набор версий HTML-страницы и прогонять парсер на этих снапшотах. Тогда изменение DOM ломает узкий тест, а не весь релиз. Это намного лучше, чем узнавать о проблеме из production через два дня и фразу почему-то новые записи не приходят.

Для корпоративных решений такой подход особенно важен, когда система строит мониторинг рынка, прайс-листов, партнерских каталогов или обновлений внешних документов.

Как тестировать Telegram-интеграции и похожие внешние каналы

Тут полезно сразу делить систему на два контура.

Outbound

Мы отправляем сообщение пользователю, менеджеру, оператору, врачу, клиенту или администратору.

Inbound

Пользователь или внешний сервис присылает нам команду, callback, статус, кнопку, подтверждение, attachment.

Что тестировать для outbound

• формат сообщения
• экранирование
• локализацию
• дедупликацию
• ретраи
• связь с доменным событием
• correlation id для трассировки

Что тестировать для inbound

• валидность payload
• маршрутизацию команды
• авторизацию и подписи, если применимо
• повторную доставку
• идемпотентность
• побочный эффект в базе и очередях

Документация Telegram Bot API и материалы по webhook-механике полезны не только для настройки, но и как источник реалистичных payload. Лучший тест здесь — не абстрактная фантазия, а реальный сохраненный update из production-like среды.

Такие интеграции часто важны в системах поддержки, уведомлений, подтверждений действий, внутренних BPM-контуров, логистических сервисах и CRM-модулях.

Как тестировать очереди, отложенные действия и регулярные задачи

Как только в системе появляется очередь, cron или отложенный workflow, у вас появляется еще один скрытый персонаж — время. А время в программных системах любит устраивать пакости молча, элегантно и без свидетелей.

Поэтому тесты для очередей и фоновых задач нужно строить не вокруг sleep и надежды, а вокруг управляемого времени.

Что здесь важно проверить

• задача выполняется один раз там, где это критично
• повторная доставка не приводит к дубликатам
• ошибка приводит к retry по правильной политике
• после исчерпания retry задача уходит в DLQ или специальный статус
• order-sensitive события обрабатываются корректно
• periodic jobs не пересекаются и не съедают друг друга
• перезапуск воркера не ломает состояние

Что помогает технически

• fake clock
• time travel
• локальный брокер в контейнере
• тестовые очереди
• явные idempotency keys
• трассировка цепочек сообщений

Если у вас используется модель workflow engine, полезно смотреть в сторону подходов, похожих на Temporal testing, где тестовая среда умеет работать со временем как с управляемым ресурсом, а не как с мистикой.

В системах уровня platFORMA, FORMA BPM, FORMA WMS и производственных решениях вроде Prime EVA это особенно критично, потому что там много фоновых процессов, зависимостей и бизнес-следствий.

Как тестировать потоки real-time данных, например голос через микрофон в браузере

Вот здесь начинается та часть современной разработки, где классический unit test уже не царь, а просто один из чиновников в большом ведомстве.

Если пользователь говорит голосом в браузере, у вас появляются:

• микрофон и разрешения браузера
• поток аудио чанков
• кодирование и декодирование
• сеть и задержки
• прерывания соединения
• серверная буферизация
• реакция UI на частичные результаты
• финальная транскрипция или действие

Как разумно делить такие тесты

• unit — формат чанков, буферизация, агрегаторы, state machine на клиенте и сервере
• component — передача чанков через mock transport
• integration — реальный websocket или streaming endpoint в тестовом окружении
• scenario — короткие сквозные тесты с заранее подготовленным аудио
• observability — метрики latency, dropped chunks, reconnect, timeout

Что важно проверять

• что части потока не теряются
• что сообщения собираются в правильном порядке
• что кратковременный обрыв сети не рушит все состояние
• что сервер корректно завершает сессию
• что UI адекватно показывает промежуточный статус
• что пользователь не получает зависшую сессию после reload

Для таких систем особенно важны synthetic и replay-проверки. То есть вы храните набор эталонных потоков и периодически воспроизводите их на тестовом контуре. Иначе вы рискуете узнать о проблеме только тогда, когда живой пользователь начнет злиться в микрофон сильнее обычного =)

Мы сталкиваемся с такими принципами в проектах, где есть real-time взаимодействие, голос, коммуникационные контуры или сложное клиент-серверное поведение, например в NaturalTTS и ряде продуктовых AI-модулей.

Как тестировать внешние webhooks

Webhook — вещь простая только в презентации. На практике webhook — это маленькая дверь в дом, через которую внешний мир может прийти с бумагами, грязными ботинками и иногда с топором.

Что обязательно проверять у webhook endpoint

• валидность схемы payload
• подпись и верификацию источника
• идемпотентность
• обработку повтора
• обработку поздней доставки
• корректность реакции на неизвестные поля
• обратную совместимость при изменении внешней схемы
• аудит и трассировку

Чего не стоит делать

• не надо завязывать все на один хрупкий giant e2e
• не надо считать, что 200 OK означает успех бизнеса
• не надо сохранять минимальный лог без возможности расследования
• не надо полагаться только на внешнюю систему как на источник истины

Очень полезная практика — сохранять сырые webhook payload в отдельное хранилище или журнал, чтобы можно было воспроизводить реальные инциденты. Иначе расследование аварии превращается в жанр мне кажется, там что-то пришло, но это не точно.

Как тестировать интеграции с ИИ, если тесты платные

Это один из самых интересных и самых болезненных участков.

Когда в системе есть генерация текста, классификация, извлечение сущностей, summarization, ranking, copilots, чаты, голосовые модули или agent-based decision loops, тесты действительно становятся платными. Потому что каждый вызов модели — это расход бюджета, времени и иногда еще и нестабильности.

Поэтому AI-тесты нельзя смешивать с обычными быстрыми regression-тестами.

Правильное деление AI-проверок по стоимости

• бесплатный слой — тесты промпт-обвязки, схем, парсинга, guardrails, постобработки, fallback-логики, маршрутизации без реального вызова модели
• дешевый слой — ограниченный набор smoke-evals на небольшой эталонной выборке
• дорогой слой — полноценные evals по расписанию, перед релизом или на выделенном этапе

Что обязательно отделять

• paid tests
• nightly AI evals
• manual review cases
• benchmark runs

То есть в CI у вас должны быть отдельные группы. Иначе команда случайно начнет гонять платные evals на каждый коммит и быстро почувствует себя как владелец казино, где рулетка крутится, а прибыль почему-то не у вас.

Материалы OpenAI Developers и инженерные заметки Anthropic хорошо подчеркивают общую идею: для AI-систем качество нужно оценивать системно, воспроизводимо и на representative-наборах задач, а не по одному красивому примеру.

Как тестировать интеграции с ИИ, если результат нельзя проверить алгоритмически

Вот это уже настоящий взрослый разговор.

Если система генерирует свободный текст, рекомендации, письма, summaries, инструкции, гипотезы, контент или ответы ассистента, то простой assert equals почти всегда бесполезен. Ответ может быть хорошим, но другим. Или плохим, но формально похожим.

Поэтому здесь применяются другие методы.

1. Reference-based evals

Есть эталонные примеры и ожидаемые характеристики результата. Не обязательно побуквенное совпадение, но есть критерии качества.

2. Rule-based graders

Часть результата можно проверять алгоритмически:

• есть ли обязательные сущности
• не нарушена ли структура
• не превышен ли лимит
• нет ли запрещенных формулировок
• сохранились ли ключевые факты

3. LLM-as-a-judge

Другой AI оценивает результат по критериям. Но тут нужна осторожность. Такой grader тоже надо калибровать, тестировать и держать под контролем.

4. Pairwise comparison

Полезно, когда вы сравниваете две версии промпта, две модели или два пайплайна и хотите понять, какая версия объективно лучше на наборе задач.

5. Human review for high-risk slices

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

На практике для бизнеса это означает следующее: не надо пытаться сделать вид, что все AI-поведение можно замкнуть на точный алгоритмический assert. В большинстве серьезных систем это ложь. Нужно честно разделять:

• что проверяется строго
• что проверяется эвристически
• что проверяется другим AI
• что проверяется человеком

Нужно ли запускать другой ИИ, чтобы тестировать ИИ

Иногда да. Но не как религию, а как инструмент.

LLM-as-a-judge полезен, когда:

• нужно оценить смысловую полноту ответа
• нужно проверить соответствие стилю
• нужно сравнить несколько вариантов ответа
• нужно быстро оценивать большое количество генераций

Но его нельзя превращать в единственный источник истины. Потому что тогда вы строите матрешку из вероятностей: один недетерминированный объект оценивает другой недетерминированный объект, а вы в это время пытаетесь объяснить директору, почему качество вроде выросло, но местами стало хуже.

Хорошая практика

• сначала алгоритмические checks там, где возможно
• потом rule-based grading
• потом LLM-judge на часть метрик
• потом выборочная человеческая валидация

Такой каскад обычно работает лучше, чем ставка на один магический grader.

Как тестировать агентные системы, если вообще непонятно, что такое нормально

Это, пожалуй, самый важный вопрос во всей статье.

Агент — это уже не просто функция, которая получает input и возвращает output. Агент может:

• планировать шаги
• использовать инструменты
• ходить в интернет или по внутренним API
• читать документы
• принимать промежуточные решения
• менять состояние
• запускать дочерние процессы
• ошибаться не на ответе, а на маршруте

Поэтому агентную систему нужно тестировать минимум на трех уровнях.

Уровень 1. Outcome

Достигнут ли правильный бизнес-результат. Не просто сказал ли агент что-то правдоподобное, а получен ли корректный итог.

Уровень 2. Process

Не было ли запрещенных действий по пути. Например, лишних вызовов tool, опасных операций, неверного порядка шагов, утечки данных, ненужных расходов.

Уровень 3. Cost and stability

Сколько шагов занял маршрут, сколько стоил, сколько занял времени, насколько воспроизводим результат.

Что особенно полезно в agent evals

• фиксированный task set
• несколько trial на одну задачу
• лог всех tool calls
• trace grading
• assert на итоговое состояние системы
• лимиты по времени, стоимости и количеству шагов

Агентные тесты часто должны проверять не только текстовый ответ, а реальный state change:

• создался ли объект в БД
• не были ли затронуты чужие данные
• не ушло ли лишнее сообщение
• не была ли вызвана запрещенная интеграция
• не вышел ли маршрут за бюджет

Если у вас есть агентная автоматизация разработки, внутренний технический copilot, AI-оператор процессов или гибридный workflow с LLM, это становится обязательным. В этом контуре особенно близок кейс FRACTAL, где автоматизация разработки и инженерных пайплайнов требует совсем другого уровня тестовой дисциплины, чем обычный CRUD-сервис.

Как тестировать сложные инфраструктурные задачи и холодный старт системы

Это как раз та часть, про которую многие вспоминают только после аварии. Хотя именно инфраструктура часто определяет, будет ли ваш красивый продукт работать после рестарта машины, разворота нового сервера, падения контейнера, миграции базы или обновления оркестрации.

Что здесь нужно проверять

• система поднимается с нуля в чистом окружении
• миграции применяются корректно
• сервисы стартуют в правильном порядке
• readiness и liveness действительно отражают состояние
• очереди и воркеры восстанавливаются после рестарта
• конфигурация окружения полна и не противоречива
• временное отсутствие зависимости не убивает весь контур
• кеш, файловое хранилище, база и брокер пересобираются предсказуемо

Как это тестировать на практике

• ephemeral environment с поднятием всего стека
• smoke после деплоя
• recreate тестовых сред с нуля
• chaos-lite упражнения на рестарт отдельных сервисов
• проверка boot sequence
• автоматический health audit после запуска

В инфраструктурно насыщенных системах это обязательная часть качества. Особенно если у вас есть несколько сервисов, брокер, база, cron, AI-воркеры, storage, webhook-consumer, streaming-компоненты.

Такие контуры характерны для производственных, учетных, логистических и AI-систем. В проектах вроде Prime EVA, Vorfahr, NaturalTTS, platFORMA инфраструктурное тестирование уже не опция.

Что обязательно должно быть у зрелой системы тестирования

• карта рисков — где именно система может причинить ущерб
• карта контуров запуска — что запускается локально, на PR, ночью, перед релизом, после релиза
• маркировка тестов — fast, slow, e2e, paid, ai, flaky-review, integration
• стабильные тестовые данные
• наблюдаемость — логи, метрики, трассировка, correlation id
• воспроизводимость — фиксированные фикстуры, версии payload, seed, controlled environment
• стоимостная модель — какие тесты дорогие и как часто их разумно запускать
• правила для AI-агентов — что именно им разрешено писать и менять

Как давать задачу Codex, Claude и другим агентам, чтобы они писали хорошие тесты

Это отдельная важная тема. Плохой промпт рождает плохие тесты. И это не потому, что агент глупый. А потому что вы поставили задачу в стиле напиши тесты, а ожидали архитектурную зрелость.

Неправильная постановка

Напиши тесты для этого сервиса.

Правильная постановка

Вот бизнес-контекст. Вот критичные инварианты. Вот что запрещено мокать. Вот что считается успешным результатом. Вот какие тесты должны быть быстрыми. Вот какие сценарии относятся к PR, а какие к nightly. Вот какие риски уже встречались в продакшене. Вот где тестировать поведение, а не implementation details.

Что стоит указывать агенту явно

• слой тестирования: unit, component, integration, contract, e2e, eval
• что является объектом проверки
• какие инварианты обязательны
• какие зависимости разрешено мокать
• какие реальные фикстуры использовать
• какая стоимость запуска допустима
• какие тесты нельзя добавлять в быстрый pipeline
• какие known failure modes уже известны

Очень полезное правило

Попросите агента сначала выдать план тестирования, а не сразу код тестов. Пусть он перечислит:

• риски
• слои
• контуры запуска
• какие проверки нужны
• какие проверки не нужны

И только потом — генерацию кода.

Это резко снижает количество бессмысленных тестов.

Как мы бы разложили это по типовым бизнес-сценариям Ingello Systems

Логистика и бронирование

Для проектов вроде Svit BUS, LEX, BusTicket, UNO Taxi тесты должны закрывать:

• алгоритмы поиска и маршрутизации
• ценообразование и скидки
• возвраты и отмены
• карты и гео-данные
• роли, кабинеты, партнерские доступы
• повторную обработку внешних событий
• оплаты и reconciliation

Корпоративные платформы

Для platFORMA, FORMA CRM, FORMA WMS, FORMA BPM, FORMA HRM ключевые тесты живут вокруг:

• прав доступа
• workflow-состояний
• документооборота
• движения товаров
• синхронизации между модулями
• регулярных задач и уведомлений
• идемпотентности и аудита

Медицина и регуляторный контур

Для Evrika, Lita, L-Doc, Rapport, Dent Ingello тестирование должно быть особенно дисциплинированным вокруг:

• структуры данных
• прав доступа и приватности
• целостности записей
• совместимости интеграций
• стабильности форм, кабинетов, маршрутов данных
• контролируемого поведения AI, если он используется

Производство, учет и интеграции

Для Prime EVA, GadFul, Carveli, SKLO особенно важны:

• сходимость учета
• цепочки производства и статусов
• внешние интеграции
• регулярные синхронизации
• массовые фоновые операции
• восстановление после сбоев

AI и автоматизация разработки

Для FRACTAL, Vorfahr, NaturalTTS нужны уже отдельные AI-evals, cost controls, трассировка tool use, grading и сценарные проверки агентных маршрутов.

Частые ошибки, которые убивают реальную пользу от тестов

• погоня за coverage как за самоцелью
• одинаковые проверки на всех слоях
• полная зависимость от моков
• слишком много e2e
• отсутствие маркировки slow и paid тестов
• отсутствие производственных canary и observability
• смешивание AI evals с быстрым CI
• попытка проверить недетерминированную систему детерминированными ассертами там, где это не работает
• отсутствие реальных production-like payload и фикстур
• делегирование агенту написания тестов без описания рисков

Практический вывод для бизнеса

Если упростить все сказанное до одного очень земного вывода, он будет таким:

Тестирование в 2026 году — это уже не приложение к разработке, а часть архитектуры бизнеса.

Потому что современные продукты — это не просто код. Это связка из доменной логики, интеграций, очередей, AI, real-time контуров, внешних событий и инфраструктуры. И если вы проверяете только один слой, остальные начинают гнить тихо, культурно и с корпоративной улыбкой.

Поэтому хороший процесс выглядит так:

• мы знаем, какие риски у системы есть
• мы понимаем, какие тесты нужны на каком слое
• мы не гоняем все подряд на каждый коммит
• мы отделяем быстрые проверки от дорогих и редких
• мы отдельно проектируем AI-evals
• мы тестируем не только код, но и маршруты, события, состояние и стоимость
• мы строим observability как часть контроля качества

Что делать, если у вас уже есть проект, но тесты в нем хаотичны

В такой ситуации обычно не нужно начинать с героической идеи покрыть все. Это путь в красивую усталость без реального результата.

Нужно сделать по-взрослому:

• выделить критичные бизнес-сценарии
• определить самые дорогие риски
• разделить систему на детерминированные и недетерминированные контуры
• выбрать базовый набор fast tests
• выделить интеграционные и e2e сценарии только для ключевых цепочек
• спроектировать AI-evals отдельно
• настроить observability и post-release smoke

И уже после этого подключать Codex, Claude и других агентов как ускорители, а не как шаманов.

Заключение

Современные AI-агенты — это не волшебная кнопка и не враги. Это усилители. Они усиливают и хорошую инженерную культуру, и плохую. Если архитектура тестирования зрелая, агенты резко ускоряют разработку. Если архитектуры нет, они ускоряют хаос.

Поэтому правильный вопрос сегодня звучит не так: может ли AI писать тесты. Конечно может. Правильный вопрос такой: умеет ли ваша компания ставить задачу на тестирование на уровне системы, риска и бизнеса.

В этом и есть разница между просто кодом и настоящей инженерией.

Если вам нужен проект, где тестирование, архитектура, автоматизация, интеграции и AI изначально проектируются как единая система, посмотрите наш подход на Ingello Systems. Мы работаем и со стартапами, и с системными компаниями: от MVP и AI-модулей до тяжелых корпоративных контуров, CRM, WMS, логистики, медицины, производственных и учетных решений. А еще мы любим разбирать хаос на детали и превращать его в управляемую систему. В этом, если честно, и есть весь кайф инженерии =)