Automatyzacja UI dla stron i aplikacji, które budujesz samodzielnie

Co agent może zrobić dla Twoich testów

• Plikiread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep i glob działają w folderze roboczym czatu, a licznik pokazuje liczbę utworzonych, edytowanych i odczytanych plików.
• Shelluruchamia Twoje polecenie testu, lintera lub kompilację lokalnie w systemie Windows, WSL lub przez SSH na serwerze, którym dysponujesz, a sukces ocenia na podstawie rzeczywistego kodu wyjścia. Niebezpieczne polecenia są zablokowane.
• Siećweb_search znajduje strony, a http_get odczytuje jedną stronę oficjalnej dokumentacji, dzięki czemu pytanie o selektor lub oczekiwanie można sprawdzić przeciwko instrukcji samego frameworka.
• Zrzuty ekranu i obrazyodczytuje tekst z zapisanego zrzutu ekranu, na przykład baneru błędu z nieudanego uruchomienia, a gen_image zapisuje rzeczywiste pliki graficzne, gdy są potrzebne.
• Orkiestracjatask dzieli niezależne sprawdzenia między równoległe sub-agentów, run_on_model wysyła jeden trudny krok do większego modelu, a skill przechowuje ponownie używalny plan, taki jak Twoja rutyna naprawcza.
• Tryby zatwierdzaniaAuto-run działa natychmiast, Ask first pauzuje przed akcjami zmieniającymi coś i pokazuje diff, a Plan only zapisuje plan i nic nie uruchamia. Plany przetrwają restarty.
• Cronuruchamia prompt zgodnie z harmonogramem, na przykład aby uruchomić Twoje polecenie testu w ustawionych godzinach i zgłosić kod wyjścia w czacie, aby przepływ, który awaryjnie się rozpadł, był pierwszą rzeczą, którą widzisz.
• Modelepodłącz dostawcę AI z chmury przez standardowy punkt końcowy API, model działający lokalnie na Twoim komputerze lub wbudowany model gotowy do użycia bez Twojego punktu końcowego. Przycisk Test sprawdza punkt końcowy przed rozpoczęciem.

Cztery zadania, które agent wykonuje w projekcie testowym

Napisz pierwszy przepływ

Najlepsze praktyki testów e2e zaczynają się od krótkiej listy przepływów, które muszą zawsze przechodzić, więc poproś FlowLatch o napisanie tylko tych. list_dir i glob pokazują, jak nazwane są Twoje istniejące testy, read_file otwiera jeden jako wzorzec, a write_file tworzy nowy plik dla przepływu logowania z kontem testowym i danymi zastępczymi. Shell następnie uruchamia Twoje polecenie testu, a karta pokazuje rzeczywisty kod wyjścia. Pierwsza wersja rzadko jest ostateczna, więc prosz o jedną zmianę na raz, na przykład o jaśniejszą nazwę lub dodanie sprawdzenia tekstu na stronie. Przed akceptacją przeczytaj nowy plik w diffie, uruchom go samodzielnie raz i zachowaj tylko wtedy, gdy pasuje do zamierzonego przepływu.

Uruchom zestaw i przeczytaj awarię

Shell uruchamia Twoje polecenie testu, a karta zachowuje pełny wynik, więc czerwony wynik to nie zgadywanka. grep wyszukuje w tym wyniku krok, który nie przeszedł, a jeśli Twój framework zapisał zrzut ekranu, odczytuje komunikat na nim. Aby zmniejszyć niestabilność w testach end-to-end, poproś FlowLatch o ponowne uruchomienie nieudanego testu tym samym poleceniem i porównanie kodów wyjścia. Przejście po przejściu wskazuje na sztywne oczekiwanie, wspólne dane testowe lub kolejność testów. Poproś o krótkie wyjaśnienie w czacie, a następnie zweryfikuj je względem wyniku przed zmianą jakiegokolwiek pliku.

Napraw selektor po zmianie układu

Czy testowanie e2e jest warte czasu dla prac frontendowych zależy od przepływu, więc najpierw obejmuj logowanie i koszyk. Gdy układ strony się zmieni, grep znajdzie każdy selektor z nim powiązany, read_file pokaże otaczające kroki, a edit_file zaproponuje stabilne etykiety lub identyfikatory testowe. W Ask first FlowLatch pauzuje przed każdą edycją i pokazuje diff, jeden plik na raz. Akceptuj linie, które wyglądają poprawnie, odrzuć pozostałe, a następnie pozwól Shell uruchomić zestaw ponownie, aby zobaczyć nowy kod wyjścia. Zachowaj mały diff, aby recenzent mógł go przeczytać w minutę.

Przenieś zestaw do innego frameworka

Przy migracji testów e2e między frameworkami zachowaj oba zestawy w repozytorium, dopóki nowy nie przejdzie. FlowLatch wypisuje stare testy za pomocą glob, odczytuje każdy za pomocą read_file i zapisuje pasujący nowy plik za pomocą write_file, jeden przepływ na raz. web_search i http_get mogą odczytać dokumentację nowego frameworka dla składni, której nie pamiętasz. Uruchom oba zestawy za pomocą Shell, porównaj kody wyjścia i zatwierdź każdy plik w Ask first przed usunięciem starego. Plany przetrwają restarty, więc długa migracja może kontynuować się następnego dnia.