Twoja aplikacja zawiera dowód
Kliv pisze prawdziwe testy dla tworzonych przez siebie aplikacji — i uruchamia je w prawdziwej przeglądarce, w oparciu o jednorazową kopię bazy danych, z potwierdzeniem każdego efektu ubocznego. Ta sama pętla, która zapisuje Twoją aplikację, zapisuje jej testy i zapewnia ich zielone działanie.
Wbudowane testowanie
Nie wygenerowany kod i trzymamy kciuki
Większość twórców AI generuje aplikację i przekazuje ją — Twoim problemem jest to, czy faktycznie działa. Kliv jest właścicielem całego stosu, na którym działa aplikacja: przeglądarki, API, reguł bezpieczeństwa, bazy danych, potoku poczty email. To właśnie sprawia, że dowód jest możliwy. Testy nie są czymś, do czego można się później przyczepić; są częścią procesu budowania aplikacji i są uruchamiane przez tę samą pętlę, która napisała kod.
Anatomia biegu
Najlepszym sposobem na zrozumienie systemu testowania jest prześledzenie jednego przebiegu od pierwszej linijki do werdyktu. Oto, co się dzieje — i co nigdy nie ma wpływu na Twoje prawdziwe dane.
Napisz
AI zapisuje testy jednostkowe w trakcie tworzenia — oryginalna Vitest i biblioteka testowa, stos będący standardem branżowym, a nie zastrzeżona imitacja. Poproś o pokrycie przepływu, a on napisze Scenario: nawiguj, klikaj, wypełniaj, potwierdzaj, w kategoriach semantycznych — przycisk po nazwie, pole przy etykiecie — a nie krucha ścieżka CSS, która zginie podczas następnego przeprojektowania.
Uruchom w prawdziwej przeglądarce
Testy przeprowadzane są w prawdziwej przeglądarce w porównaniu z Twoją rzeczywistą aplikacją — prawdziwe renderowanie, prawdziwe logowanie, prawdziwe bezpieczeństwo na poziomie wiersza. Nie kpi się z niczego, co ma znaczenie: jeśli zmiana uprawnień umożliwi jednemu użytkownikowi odczytanie danych innego użytkownika, test zakończy się niepowodzeniem w taki sam sposób, jak Twoja aplikacja.
Forkuj bazę danych
Zanim Scenario dotknie danych, otrzymuje jednorazowe rozwidlenie Twojej bazy danych — ten sam schemat, te same zasady, żaden z Twoich wierszy nie jest zagrożony. Tworzy, edytuje i usuwa prawdziwy bieg i ląduje na rozwidleniu; Twoje pliki i stan handlowy są klonowane w ten sam sposób. Po zakończeniu biegu widelec zostaje wyrzucony.
Uchwyć wyjście
Emaile, webhooki i połączenia od stron trzecich są przechwytywane, a nie uruchamiane. Test może wykazać, że email powitalny został wysłany, do kogo i z czym — a żaden email nigdy nie opuścił budynku. Twoje integracje pozostają ciche, podczas gdy Twoja logika jest ćwiczona.
Pokwitowanie
Każde uruchomienie rejestruje, co faktycznie zrobiła aplikacja: które wiersze napisała, jakie emaile wysłała, jakie zewnętrzne połączenia próbowała wykonać – każde z nich zostało oznaczone jako zaakceptowane, przechwycone lub odrzucone z podaniem przyczyny, aż do reguły bezpieczeństwa, która blokowała zapis. Nie tylko czerwony czy zielony: co się stało i dlaczego.
Werdykt
Wyniki są zwracane według kontroli, dla każdego pliku — błędnego potwierdzenia, kroku, który się zepsuł, wraz z potwierdzeniem przebiegu. Chodzi o awarię strukturalną: to ona pozwala tej samej pętli, która napisała kod, znaleźć błąd, naprawić go i uruchomić ponownie.
Brama
Publikacja wyników testów. Nieudany Scenario wstrzymuje wydanie, zanim dotrze do użytkowników — więc „działało, kiedy to zbudowaliśmy” staje się „działa teraz”, weryfikowane przy każdej zmianie, a nie zapamiętywane z wersji demonstracyjnej.
Co system testowy wie, jak zrobić
Wbudowany, uruchamiany dla Ciebie i czytelny, gdy chcesz spojrzeć.
Prawdziwy stos testowy
Oryginalny Vitest, biblioteka testowa i jest-dom działające w przeglądarce — te same narzędzia, z których korzystają profesjonalne zespoły, więc testy czyta się jak testy, a nie jak w dialekcie dostawcy.
Testy Scenario
Kompleksowe przepływy zapisane w kategoriach semantycznych — znajdź przycisk według jego roli, pole według etykiety — sterując prawdziwą aplikacją w sposób, w jaki zrobiłby to użytkownik.
Jednorazowa baza danych
Każdy Scenario działa na rozwidleniu Twojej prawdziwej bazy danych. Zapisy są akceptowane, potwierdzane i odrzucane — Twoje dane nigdy nie są częścią eksperymentu.
Nic nie przecieka
Przebiegi testowe przechwytują emaile, elementy webhook i wywołania oprogramowania sprzęgającego zamiast je wysyłać — możesz udowodnić, że miały one miejsce bez ich wystąpienia.
Każdy bieg posiada paragon
Rejestr wszystkich skutków ubocznych wywołanych przez test – zaakceptowanych, przechwyconych lub odrzuconych, wraz z powodem. Ślad, a nie tylko sygnalizacja świetlna.
Historia i brama
Uruchomienia są śledzone w czasie, a pozytywne wyniki testów są publikowane — weryfikacja to stały stan Twojej aplikacji, a nie jednorazowe zdarzenie.
Często zadawane pytania
Kto pisze testy?
AI podczas kompilacji domyślnie wykonuje testy jednostkowe w standardowym stosie. Poproś o pokrycie przepływu, a on zapisuje dla niego Scenario. Każdy test to czytelny kod w Twojej aplikacji; możesz sprawdzić dowolne z nich i nigdy nie musisz.
Czy testy dotykają moich prawdziwych danych?
Nie. Scenariusze działają w oparciu o jednorazowy fork bazy danych — zapisy są tam akceptowane i usuwane wraz z forkiem po zakończeniu przebiegu. Pliki i stan handlu są klonowane w ten sam sposób, więc nawet test, który usuwa wszystko, nie usuwa niczego.
Czy test wyśle prawdziwe emaile, czy uderzy w moje integracje?
Nie — ruch wychodzący jest przechwytywany, a nie wysyłany. Przebieg rejestruje, że email zostałby wysłany, do kogo i z czym, a test może to potwierdzić. Twoi klienci i połączone narzędzia nigdy nie zobaczą testu.
Co zobaczę, gdy test się nie powiedzie?
Wyniki poszczególnych kontroli — plik, kontrola, stwierdzenie, które zakończyło się niepowodzeniem — plus potwierdzenie skutków ubocznych przebiegu z podaniem powodu, dla którego każdy z nich został dopuszczony lub odrzucony. Dzięki tej strukturze AI może zdiagnozować swój własny błąd i go naprawić, zamiast zgadywać na podstawie zrzutu ekranu.
Czy testy realizują moje zasady bezpieczeństwa?
Tak — scenariusze działają z rzeczywistym logowaniem i rzeczywistymi regułami na poziomie wiersza, a nie z wyśmiewaną sesją. Jeśli zmiana pozwala użytkownikowi zobaczyć dane, które nie należą do niego, test zakończy się niepowodzeniem, zanim użytkownik to zrobi.
Czy nieudany test może zablokować wydanie?
Tak. Scenario weryfikuje publikację bramkową — czerwony przebieg wstrzymuje publikację do czasu, aż ponownie zmieni kolor na zielony. Bramka stanowi różnicę między nadzieją, że ostatnia zmiana była bezpieczna, a świadomością, że została sprawdzona.
Opisz swoją aplikację. Udowodnij to.
Wbudowane środki wbudowane razem: testy przeprowadzane są na tej samej aplikacji, którą widzą użytkownicy — zatem nieudany test realizacji transakcji jest nieudaną realizacją transakcji, a nie próbą.
