До вашого застосунку додається доказ
Kliv пише реальні тести для програм, які створює — і запускає їх у реальному браузері на одноразовій копії вашої бази даних із квитанцією про кожен побічний ефект. Той самий цикл, який записує ваш застосунок, записує його тести та керує ними зеленими.
Вбудоване тестування
Не згенерований код і схрещені пальці
Більшість AI-конструкторів створюють застосунок та передають її — ваша проблема — чи працює вона насправді. Kliv володіє всім стеком, у якому працює застосунок: браузером, API, правилами безпеки, базою даних, конвеєром email. Ось що робить доказ можливим. Тести – це не те, до чого ти кинешся пізніше; вони є частиною того, як створюється застосунок, керуючи тим самим циклом, у якому був написаний код.
Анатомія бігу
Найкращий спосіб зрозуміти систему тестування — пройти один прогін від першого рядка до вердикту. Ось що відбувається — і те, що ніколи не торкається ваших справжніх даних.
Напишіть
AI пише модульні тести під час збирання — справжній Vitest і бібліотека тестування, галузевий стандартний стек, а не запатентована імітація. Попросіть охопити потік, і він напише Scenario: навігація, клацання, заповнення, підтвердження, семантично — кнопка за назвою, поле за міткою — а не крихкий шлях CSS, який вмирає під час наступного редизайну.
Запустити в реальному браузері
Тести виконуються в реальному браузері проти вашої фактичної програми — реальне відтворення, реальний вхід, реальна безпека на рівні рядків. Нічого важливого не висміюють: якщо зміна дозволів дозволяє одному користувачеві читати дані іншого, тест проходить так само, як ваш застосунок.
Форк бази даних
Перш ніж Scenario торкнеться даних, він отримає одноразовий форк вашої бази даних — та сама схема, ті самі правила, жоден із ваших рядків не під загрозою. Створює, редагує та видаляє run for real and land on the fork; ваші файли та комерційний стан клонуються таким же чином. Коли біг закінчується, вилку викидають.
Захопити вихід
Email, веб-хуки та виклики третіх сторін захоплюються, а не запускаються. Тест може стверджувати, що привітальний email надійшов, кому, з чим — і жоден email ніколи не залишає будівлю. Ваші інтеграції залишаються тихими, поки ваша логіка тренується.
Квитанція
Кожен запуск записує, що насправді робила застосунок: які рядки вона написала, які email надсилала б, які зовнішні виклики вона намагалася зробити — кожен із них позначено як прийнятий, перехоплений чи відмовлений із зазначенням причини, аж до правила безпеки, яке блокувало запис. Не просто червоний чи зелений: що сталося і чому.
Вирок
Результати повертаються для перевірки, для кожного файлу — невдалого твердження, кроку, який зламався, разом із квитанцією про виконання. Суть у структурованій помилці: це те, що дозволяє тому самому циклу, який написав код, знайти помилку, виправити її та запустити знову.
Ворота
Публікація результатів тестування. Збій Scenario зупиняє випуск до того, як він досягне ваших користувачів — тому «він працював, коли ми його створювали» стає «це працює зараз», що перевіряється під час кожної зміни, а не запам’ятовується з демонстрації.
Те, що вміє робити тестова система
Вбудований, працює для вас і читається, коли ви захочете подивитися.
Справжній тестовий стек
Справжній Vitest, бібліотека тестування та jest-dom, що працюють у браузері — ті самі інструменти, які використовують професійні команди, тому тести читаються як тести, а не як діалект постачальника.
Тести Scenario
Наскрізні потоки, написані семантичними термінами — знайдіть кнопку за її роллю, поле — за міткою — керуйте справжньою застосунком так, як це зробив би користувач.
Одноразова база даних
Кожен Scenario працює проти форка вашої реальної бази даних. Записи приймаються, підтверджуються та відхиляються — ваші дані ніколи не є частиною експерименту.
Нічого не тече
Тестування фіксує email, веб-хуки та виклики конектора замість того, щоб надсилати їх — ви можете довести, що вони відбулися без них.
Кожен запуск має квитанцію
Журнал усіх побічних ефектів, спричинених тестом — прийнятих, зафіксованих або відхилених із зазначенням причини. Слід, а не просто світлофор.
Історія і ворота
Запуски відстежуються протягом тривалого часу, а проходження тестів забезпечує публікацію — перевірка є постійним станом вашого застосунка, а не одноразовою подією.
Загальні запитання
Хто пише контрольні роботи?
AI робить, як він будує — модульні тести за замовчуванням у стандартному стеку. Попросіть, щоб потік був покритий, і він записує для нього Scenario. Кожен тест є читабельним кодом у вашому застосунку; ви можете перевірити будь-яке з них, і вам ніколи не доведеться.
Чи впливають тести на мої справжні дані?
Ні. Сценарії виконуються на одноразовому форку вашої бази даних — записи приймаються там і викидаються разом із форком, коли цикл завершується. Файли та комерційний стан клонуються таким же чином, тому навіть тест, який видаляє все, не видаляє нічого.
Чи тест надсилатиме справжні email чи вразить мої інтеграції?
Ні — вихідний трафік фіксується, а не надсилається. Прогон фіксує, що email був би відправлений, кому та з чим, і тест може підтвердити це. Ваші клієнти та підключені інструменти ніколи не бачать тесту.
Що я бачу, коли тест проходить невдало?
Результати перевірки — файл, перевірка, твердження, що не вдалося — плюс отримання побічних ефектів із зазначенням причини дозволу або відмови в кожному. Саме ця структура дозволяє AI діагностувати власну помилку та виправити її, а не вгадувати за знімком екрана.
Чи відповідають тести моїм правилам безпеки?
Так. Сценарії виконуються з реальним входом за справжніми правилами на рівні рядків, а не за імітованим сеансом. Якщо зміна дозволяє користувачеві бачити дані, які не належать йому, тест проходить невдало раніше, ніж користувач зможе.
Чи може невдалий тест блокувати випуск?
так Scenario вердиктує публікацію — червоний запуск зупиняє випуск, доки знову не стане зеленим. Шлюз — це різниця між надією, що остання зміна була безпечною, і знанням, що її перевірено.
Опишіть свій застосунок. Доведіть це.
Вбудований означає, що створений разом: тести виконуються з тією самою застосунком, яку бачать ваші користувачі, тому невдала перевірка є невдалою перевіркою, а не імітацією.
