Jak naprawdę wygląda harmonogram migracji z Selenium

Sytuacja, w jakiej byli

We wrześniu 2024 roku zespół inżynierski Zenjob opisał na Zenjob Tech Blog swoją migrację z Selenium na Playwright. Na początek podali atrakcyjne liczby: zestaw, który wykonywał się 35 minut, teraz wykonuje się w około 7 minut.

Zestaw nie był duży. Sto przypadków testowych rozłożonych na osiem równoległych zadań w Jenkinsie. Według standardów większości organizacji to zestaw mały lub średni. Wielu dostawców wyceniłoby jego migrację na dwa tygodnie.

Migracji nie napędzała szybkość, a przynajmniej nie przede wszystkim. Wpis zespołu mówi jasno: niestabilność testów w Selenium „utrzymywała się” mimo dodanej synchronizacji i dedykowanych danych testowych i wymagała „ciągłych poprawek”. Ich konfiguracja nie miała też wbudowanego raportowania. Inżynierowie nie tylko uruchamiali testy; zarządzali całym procesem wsparcia wokół nich, żeby w ogóle były przydatne.

Co faktycznie zrobili

Zanim napisali choćby jeden test w Playwrighcie, w Zenjob powstało RFC. Porównali Selenium, Cypress i Playwright, przedstawili swoje rozumowanie i rozesłali dokument do całego zespołu inżynierskiego do komentarzy. Migrację zaczęli dopiero po zakończeniu tego procesu.

Warto się nad tym zatrzymać. RFC to nie biurokracja. To mechanizm, dzięki któremu migracja zdobywa budżet i mandat. Każdy inżynier, który później będzie przeglądał testy w Playwrighcie, utrzymywał je lub kwestionował podczas incydentu, został już zaproszony do zapoznania się z uzasadnieniem. To ma znaczenie. Koszt społeczny migracji (czas i energia potrzebne, by cała organizacja przyjęła nowe podejście) jest realny i prawie nigdy nie pojawia się w niczyim szacunku czasu.

Po zamknięciu RFC zespół uruchamiał oba zestawy równolegle: dotychczasowe testy w Selenium działały dalej, podczas gdy powstawały testy w Playwrighcie, a proporcja powoli się przesuwała, aż stary zestaw można było wycofać. Wpis opisuje, jak „stopniowo zwiększali liczbę testów w Playwrighcie i zmniejszali liczbę testów w Selenium”. To ostrożne podejście. Unika jednorazowego przełączenia i sprawia, że pipeline nigdy nie zależy całkowicie od zestawu, którego zespół jeszcze w pełni nie zweryfikował.

Jest też drogie, bo przez miesiące utrzymujecie dwa zestawy jednocześnie.

Ile ich to kosztowało

Osiem miesięcy. Na sto testów.

Ta liczba zasługuje na to, by być nagłówkiem tego tekstu, a nie przypisem. Zenjob nie potrzebował ośmiu miesięcy, bo był niezorganizowany czy powolny. Potrzebował ośmiu miesięcy, bo tyle naprawdę kosztuje starannie przeprowadzona migracja: napisanie i rozesłanie RFC, równoległe uruchamianie obu zestawów, utrzymywanie zielonego pipeline’u, gdy produkt nadal był wydawany, radzenie sobie z niespodziankami, które pojawiają się w połowie migracji, i wreszcie spokojne wycofanie zestawu Selenium.

Dostawcy narzędzi do automatycznej konwersji zwykle podają terminy liczone w dniach. Niektóre porównania frameworków publikowane w sieci zakładają jeszcze krótsze okresy dla zestawów podobnej wielkości. Warto spokojnie zapytać, co obejmują te terminy. Zwykle obejmują mechaniczne tłumaczenie składni testów. Rzadko obejmują okres równoległego działania, przerabianie danych testowych albo tygodnie, gdy inżynierowie po raz pierwszy spotykają nowy framework na żywym pipelinie, a przypadki brzegowe wychodzą jeden po drugim.

Wykres poniżej pokazuje czas wykonania przed i po, według danych zespołu.

Po migracji pipeline korzystał z ośmiu równoległych workerów; lokalnie używano dwóch. Zespół podaje skrócenie czasu wykonania testów o 80%, z 35 minut do około 7. zmierzone

Podczas migracji pojawił się jeden istotny problem. Opcja konfiguracyjna Playwrighta fullyParallel, która włącza pełną równoległość we wszystkich plikach testów, sprawiła, że część testów zaczęła zawodzić. Zespół ją wyłączył. Po wyłączeniu, jak podaje wpis, testy osiągnęły „stabilne działanie”.

To przydatna, konkretna lekcja. fullyParallel to jedna ze sztandarowych funkcji Playwrighta, często przywoływana jako argument za migracją. To także funkcja budowana i testowana na nowych zestawach, od początku projektowanych pod równoległe wykonanie. Zmigrowany zestaw niesie założenia ze swojego poprzedniego życia: o kolejności wykonania, o współdzielonym stanie, o danych testowych przygotowanych z myślą o sekwencyjnych przebiegach. Włączenie fullyParallel w zmigrowanym zestawie jest w praktyce eksperymentem. Zenjob przeprowadził ten eksperyment i okazało się, że nie działa. Rozwiązaniem było wyłączenie funkcji, co jest rozsądnym wynikiem. Warto jednak zauważyć, że liczby dotyczące szybkości we wpisie dotyczą zestawu działającego bez pełnej równoległości.

Liczba, której nie opublikowali

Deklarowanym powodem migracji była niestabilność. Wstęp opisuje niestabilność utrzymującą się mimo poprawek synchronizacji i dedykowanych danych testowych i określa ją jako wymagającą ciągłych poprawek. To wyraźnie istotna część powodu, dla którego zespół w ogóle zainwestował w migrację.

Wpis nie podaje wskaźnika niestabilności po migracji.

To nie jest krytyka zespołu ani tekstu. Niestabilność naprawdę trudno zmierzyć tak, żeby powstała porównywalna liczba. Szybkość jest prosta: porównuje się znaczniki czasu przed i po. Niestabilność wymaga zdefiniowania, co liczy się jako niestabilny wynik, wybrania okresu pomiaru na tyle długiego, by był reprezentatywny, i kontrolowania zmian w samym zestawie w tym czasie. Szybkość daje czyste „przed i po”; niestabilność rzadko.

Ale tę lukę warto nazwać jako wzorzec. Zespoły migrują częściowo z powodu niestabilności, a raportują szybkość, bo szybkość da się zmierzyć, a liczba jest dobra. Jeśli oceniacie migrację, pytanie „o ile szybszy jest zestaw” ma jasną odpowiedź. Pytanie „o ile spokojniejsze jest utrzymanie” prawie nigdy jej nie ma, choć zwykle jest ważniejsze.