Masz kopię testową swojego sklepu, konto testowe i folder z testami i chcesz wiedzieć, czy logowanie, dodawanie do koszyka i finalizacja zamówienia działają poprawnie po dzisiejszej zmianie. To automatyczne testowanie webowe w jego najmniejszej formie: jeden przepływ, jedna komenda testowa, jeden wynik, który możesz odczytać. FlowLatch otwiera folder, uruchamia komendę przez Shell i pokazuje prawdziwy kod wyjścia na karcie. Jeśli przepływ się nie powiedzie, wskazuje linię i proponuje poprawkę jako diff, a Ty decydujesz, czy ją zaakceptować. Poniższe kroki wymagają 4 działań od folderu do wyniku. Działaj tylko na aplikacji, którą budujesz lub masz uprawnienia do testowania, użyj konta testowego i danych zastępczych, a w kroku płatności użyj trybu testowego własnej konfiguracji płatności, nigdy prawdziwej karty. Sprawdzenie e-maili idź do skrzynki testowej ustawionej do testu.
Uruchom FlowLatch, wybierz folder zawierający Twoje testy jako folder roboczy i wybierz opcję Ask first, aby każda akcja zmieniająca coś czekała na Twoją zgodę. Połącz model, jeśli jeszcze tego nie zrobiłeś, i użyj przycisku Test, aby sprawdzić punkt końcowy.
Zapytaj o strukturę testów. list_dir i glob pokazują pliki, a read_file otwiera proces płatności, dzięki czemu Ty i agent zaczynacie od tego samego tekstu przed uruchomieniem lub zmianą czegokolwiek. Każda akcja pojawia się na czacie jako karta z wynikiem.
Powiedz agentowi, której komendy testowej używa Twój projekt. Shell uruchamia ją w systemie Windows lub w WSL, a karta pokazuje pełne wyjście i prawdziwy kod wyjścia, a nie podsumowanie. Rozwiń kartę, jeśli chcesz zobaczyć każdą linię, i użyj grep w wyjściu, aby przejść do nieudanego kroku.
W przypadku niepowodzenia zapytaj, co mówi wyjście. Agent proponuje edycję jako diff, a nic nie jest zapisywane, dopóki jej nie zaakceptujesz. Odrzuć to, co wygląda źle, a następnie uruchom komendę ponownie, aby zobaczyć nowy kod wyjścia. Powtarzaj, aż przepływ przejdzie lub będziesz wiedział, co zmienić w aplikacji.
tests/wylistowanetests/checkout-flow-test.txtzaładowaneyour test commandexit 0FAIL reports/0 dopasowań# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textTen szablon to zwykły tekst i znajduje się w repozytorium obok Twoich testów. Twój własny framework testowy zamienia każdy krok w kod, a FlowLatch używa pliku jako specyfikacji, gdy pisze ten kod, uruchamia go i porównuje wynik z trzema liniami expect. Zmień nazwę produktu i strony, aby pasowały do Twojej własnej aplikacji testowej.
Zacznij od zapytania, gdzie znajdują się testy. list_dir pokazuje foldery, glob wylicza każdy plik pasujący do wzorca, takiego jak testy kasy, a read_file otwiera te, które Cię interesują, abyś mógł zobaczyć, jak przepływ jest zbudowany dzisiaj. grep wyszukuje następnie selektorów i oczekiwania, których używają. Wszystko to tylko czyta, więc jest rozsądnym pierwszym krokiem w trybie Plan only, który tworzy plan i nic nie uruchamia. Plan przetrwa restart, więc możesz wrócić do niego jutro. Kiedy będziesz gotowy na prawdziwe uruchomienia, przełącz się na Ask first i przeczytaj plan jeszcze raz. Zapisz przepływy, które są już pokryte, aby wiedzieć, które brakuje testu.
Po aktualizacji środowiska uruchomieniowego niepowodzenia w zestawie e2e często wynikają z środowiska, a nie z Twojej aplikacji, więc przeczytaj pierwszy błąd przed dotknięciem testu. Shell uruchamia Twoją komendę testową, a karta przechowuje pełne wyjście i prawdziwy kod wyjścia, który jest jedynym uczciwym przejściem lub niepowodzeniem. grep może wyciągnąć nieudany krok z długiego dziennika. Poproś o zwykłe wyjaśnienie błędu w czacie, porównaj go z wyjściem i dopiero wtedy zdecyduj, czy plik testowy wymaga edycji. Jeśli błąd wskazuje brakujący pakiet lub zmienioną ustawienie, napraw środowisko najpierw i uruchom tę samą komendę ponownie. Często zestaw przechodzi następnie bez żadnej edycji, a kod wyjścia na karcie to dowodzi.
Utrzymanie selektorów w automatyzacji testów interfejsu użytkownika to najczęstsza praca, ponieważ zmieniony układ łamie selektory, które były z nim powiązane. grep znajduje stary selektor w każdym pliku, read_file pokazuje kroki wokół niego, a edit_file proponuje stabilną etykietę lub identyfikator testu w jego miejscu. W Ask first agent pauzuje i pokazuje diff. Zaakceptuj linie, które wyglądają poprawnie, a następnie pozwól Shell uruchomić komendę ponownie. Zielony kod wyjścia po edycji to wynik, którego chciałeś, a diff pozostaje w historii repozytorium dla następnego recenzenta. Jeśli komenda nadal się nie powiedzie, przeczytaj nowe wyjście przed poproszeniem o kolejną zmianę, ponieważ druga edycja na podstawie złego przypuszczenia utrudnia zobaczenie przyczyny. Zachowaj każdy diff na tyle mały, aby dało się go przeczytać w jednej sesji.
Gdy test ui e2e się nie powiedzie, prawdziwą przyczyną często jest stałe oczekiwanie, wspólne dane testowe lub kolejność testów, a nie aplikacja. Poproś FlowLatch o uruchomienie nieudanego testu kilka razy tą samą komendą i raport każdego kodu wyjścia. Mieszane wyniki oznaczają, że test jest niestabilny. Jeśli Twój framework zapisał zrzut ekranu, odczytuje tekst na nim, a tekst strony z nieudanego uruchomienia dodaje drugą wskazówkę. Napraw oczekiwanie lub dane w diffie, przejrzyj go i uruchom test ponownie. Nadaj każdemu testowi własne dane i zresetuj go, poczekaj na widoczny warunek zamiast stałej pauzy i utrzymaj niezależność testów od kolejności innych. Powtórz uruchomienie jeszcze raz po poprawce; jedno przejście niewiele dowodzi.
