Dwa tygodnie, 200 testów i część, którą wszyscy pomijają

Co skłoniło ich do zmiany

Lingvano to austriacka aplikacja do nauki języka migowego. Do października 2023 roku ich zestaw testów end-to-end rozrósł się do ponad 200 testów w Cypressie. Zespół nie narzekał na to, że Cypress zawiódł katastrofalnie; chodziło o cztery konkretne ograniczenia, które razem coraz bardziej im doskwierały.

Lokalne uruchomienia były na tyle wolne, że inżynierowie podczas pracy izolowali testy znacznikami .only: to sposób, który rozwiązuje bieżący problem i po cichu zwiększa dług. Każdy znacznik, który zostaje w kodzie, to test, który domyślnie już się nie uruchamia, a zestaw z wystarczającą ich liczbą może znacznie odejść od pokrywania prawdziwej aplikacji. Sharding, oczywiste lekarstwo na wolne testy, był dostępny tylko w płatnym planie Cypressa. Obsługa WebKita była oznaczona jako eksperymentalna. Lisa Weilguni, która w październiku 2023 roku opisała doświadczenia zespołu na blogu inżynierskim Lingvano, uznała, że w połączeniu te powody uzasadniają przeprowadzkę.

Narzędzie AI, które było pierwsze

Zanim zespół znalazł działającą metodę, spróbował konwersji za pomocą GPT-4. Wynik opisano we wpisie bez ogródek:

„Proponował nieistniejące asercje i przestarzałą składnię”.

Porzucili to podejście. To najbardziej przydatne zdanie w całym artykule i łatwo je przeoczyć.

GPT-4 nie wygenerował bełkotu. Wygenerował wiarygodnie wyglądający kod Playwrighta: kod, który wywoływał metody API zapisane we właściwym stylu i zawodził tylko dlatego, że te metody nie istnieją. To jest ten rodzaj błędu, który ma znaczenie. Narzędzie, które produkuje oczywiste bzdury, zostaje przyłapane przy pierwszym przeglądzie. Narzędzie, które produkuje pewnie wyglądający, błędny kod, zostaje przyłapane przy uruchomieniu testów, po merge’u albo wcale, jeśli pierwotne pokrycie było słabe.

To, że GitHub Copilot, używany bezpośrednio w edytorze obok narzędzia migracyjnego Playwrighta i zewnętrznych konwerterów, poradził sobie lepiej, nie jest kwestią jakości modelu. To kwestia kontekstu. Copilot, pracując na prawdziwych plikach, widzi otaczające importy, faktycznie używaną wersję Playwrighta i wzorce asercji, które już są w projekcie. Osobny prompt do GPT-4 widzi tylko to, co do niego wkleisz. Lepsze wyniki daje często ten model, który dostał więcej sprawdzonego kontekstu ograniczającego jego podpowiedzi.

Co faktycznie zrobili i dlaczego harmonogram się utrzymał

Ostateczny sposób pracy łączył trzy rzeczy: GitHub Copilota do podpowiedzi w trakcie przechodzenia przez pliki testów, narzędzie migracyjne Playwrighta do prostych przekształceń strukturalnych i zewnętrzne konwertery do reszty mechanicznej pracy. Zespół przeniósł wszystkie ponad 200 testów w mniej więcej dwa tygodnie.

Dwa tygodnie były tu możliwe z powodów, które warto nazwać wprost. Zestaw testów miał znany, ograniczony rozmiar. Zespół rozumiał aplikację. A Cypress i Playwright są na tyle podobne składniowo, że wiele testów dało się przełożyć przy minimalnej pracy ręcznej. Inne opublikowane harmonogramy migracji różnią się ogromnie w zależności od wieku testów, języka źródłowego i tego, jak mocno testy są związane z wnętrzem frameworka. Migracja z Selenium w Javie albo z zestawu budowanego przez wiele lat z dużą ilością własnej infrastruktury nie będzie miała tych cech. Dwa tygodnie to prawdziwy wynik w konkretnym kontekście, a nie ogólny punkt odniesienia.

Dwie liczby i dlaczego potrzebujecie obu

Tytuł wpisu mówi o 70%. Ta liczba pochodzi z uruchomienia lokalnego.

Lokalne wykonanie spadło z 1 minuty 27 sekund do 25 sekund. zmierzone

Czas w CI spadł z 6 minut 38 sekund do 3 minut 43 sekund. zmierzone

Poprawa lokalna wynosi 71%, co tytuł wpisu zaokrągla do 70%. Jako decyzja redakcyjna w nagłówku jest to do obrony. Poprawa w CI wynosi 44%. Różnica między tymi liczbami nie jest błędem zaokrąglenia. Jest strukturalna.

Uruchomienie lokalne mierzy to, nad czym framework ma bezpośrednią kontrolę: start procesu, inicjalizację przeglądarki i wykonanie testów. Gdy Playwright robi to wydajniej niż Cypress, oszczędność widać w całości. Pipeline CI zawiera to wszystko oraz checkout, instalację zależności, kroki budowania, wysyłanie artefaktów i raportowanie. Playwright nie dotyka żadnej z tych rzeczy. Ta część czasu pipeline’u, która leży poza runnerem testów, w ogóle się nie zmienia. Im większy narzut ma wasz pipeline, tym mniejsza widoczna poprawa netto.

Menedżer, który przeczyta „70% szybciej” i zbuduje na tej liczbie uzasadnienie oszczędności, zobaczy w praktyce 44%. To przewidywalna konsekwencja mierzenia zmiany frameworka na całym pipelinie i dokładnie ten rodzaj rozminięcia oczekiwań, który z perspektywy czasu podkopuje zaufanie do projektu. Obie liczby powinny być zawsze podawane razem.

Czego nie oznaczały zielone testy

Gdy testy już przechodziły, pojawiły się dwa nowe problemy.

Obsługa WebKita (jeden z głównych atutów Playwrighta w porównaniu z Cypressem) okazała się, słowami Weilguni, „dość wolna i niestabilna w naszym pipelinie GitHub CI”, mimo że lokalnie na Macu działała poprawnie. To znany wzorzec: WebKit w Playwrighcie działa na skompilowanym porcie, a nie na przeglądarce systemowej, i jego zachowanie na linuksowym CI może się różnić od natywnego środowiska macOS. Zespół zyskał pokrycie wielu przeglądarek, ale odziedziczył koszty utrzymania, których nie przewidział.

Poważniejszym ograniczeniem okazał się Mock Service Worker. Zespół używał MSW do przechwytywania żądań sieciowych w testach Cypressa. Playwright, jak zauważa Weilguni, nie obsługuje MSW w kontekście okna, co zmusiło zespół do porzucenia dotychczasowej konfiguracji MSW na rzecz wbudowanego w Playwright przechwytywania ruchu sieciowego.

MSW to dobry przykład szerszego wzorca: zależności narzędziowe wydają się poboczne, dopóki nie zaczniecie migracji, a wtedy okazują się nieobsługiwane albo wymagają pełnej strategii zastąpienia. Przydatny audyt przed migracją nie ogranicza się do samych plików testów. Obejmuje każdą bibliotekę, od której te testy zależą, z jasną odpowiedzią, co się z nią stanie w nowym środowisku.