Що потрібно знати бізнесу про сучасну ШІ-розробку та тестування

Я багато разів бачив, як бізнес намагався вайбкодити сам або наймав учорашніх студентів без досвіду реального програмування і проєктування для написання застосунків дешево й швидко. Що може піти не так? Більше не треба знати програмування — говориш своєю мовою, ШІ тобі все пише, можна навіть попросити його покрити тестами і зробити все за найкращими практиками архітектури... Так же? Чи ні? =) Ті, хто писав щось складніше за міні-парсер або простенькі інтеграції (які взагалі можна знайти безкоштовно і не писати), розуміють, що халява закінчується швидко. Щойно база коду зростає, ШІ починає галюцинувати, дублювати код, створювати маячні бізнес-процеси, плутатися, і чим більше ти пишеш йому "ні, зроби нормально, зроби добре", тим гірше він робить. Знайомо? Обговоримо, як писати код швидше й дешевше, але при цьому мінімізувати кількість сивого волосся, мертвих нейронів і дофамінових ям.

Як правильно писати тести для 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, логістики, медицини, виробничих і облікових рішень. А ще ми любимо розбирати хаос на деталі й перетворювати його на керовану систему. У цьому, якщо чесно, і є весь кайф інженерії =)