Co dělat, když nástroj pro automatizaci testů ztratí podporu
Nástroj, na kterém stojí vaše testovací sada, se přestal vyvíjet. Testy mohou dál běžet, ale nové verze prohlížeče, Node.js nebo dalších závislostí mohou postupně komplikovat údržbu a vyžadovat různá náhradní řešení.
Chvíli to funguje. Problém je, že investice do dalších náhradních řešení nezlepšuje pokrytí ani rychlost testů. Tým platí především za udržení současného stavu.
V čem je problém
Nástroj po ukončení oficiální podpory už od původního týmu nedostává běžné opravy pro nové verze prohlížečů nebo závislostí. Komunitní fork může pokračovat, jeho rozsah a důvěryhodnost je však třeba posoudit samostatně. Týká se to několika situací:
Nástroj, jehož vývoj oficiálně skončil. Příkladem je Protractor, jehož oficiální podpora skončila. Existující sada může dál běžet, ale nepřibývají běžné opravy ani podpora nového prostředí.
Nástroj, který žije, ale konkrétní sada kolem něj ne. U starší sady v Selenium bývá problémem její architektura, ne samotné Selenium. Pevná čekání, selektory navázané na strukturu stránky nebo testovací data promíchaná v kódu mohou zvyšovat rozsah oprav. Stav nástroje a kvalitu kódu či architektury je proto třeba posuzovat samostatně.
Společné mají to, že lze s jejich nedostatky nějakou dobu vydržet. Právě proto se to táhne celé roky.
Kdy je čas odejít
Ne vždy okamžitě. Rozhodnutí závisí na tom, kolik vás náhradní řešení reálně stojí.
Pokud se nástroj neposouvá dál, ale vaše sada je stabilní, pokrývá to podstatné a nikdo se jí nemusí každý týden věnovat, můžete zůstat. Nemá smysl migrovat jen kvůli pocitu, že „je to staré“.
Pokud však před každým nasazením někdo opravuje testy, přestože aplikaci nikdo nerozbil, pokud nástroj neumožňuje pokrýt potřebné scénáře nebo tým uvízl na verzi prohlížeče, kterou už zákazníci nepoužívají, platíte za setrvání více než za přechod.
Jak to řešíme
Nepřepisujeme sadu řádek po řádku. Hodnotu nesou scénáře a ověření – roky znalostí o tom, jak se má váš produkt chovat. Právě ty přeneseme. Kód, ve kterém jsou dnes zapsány, je zároveň zdrojem vašich problémů, proto ho do nové sady nekopírujeme.
Častým cílem je Playwright: podporuje několik prohlížečů, automaticky čeká na požadovaný stav prvků a zvládá scénáře s více kartami či doménami. Novou sadu navrhujeme pro snazší údržbu – využíváme vhodnou abstrakci obrazovek, stabilní identifikátory a oddělená testovací data.
Přenos probíhá postupně, scénář po scénáři, podle priority. Stará a nová sada mohou nějakou dobu běžet vedle sebe; pomocí mapy pokrytí se přitom sleduje, která sada kontroluje jednotlivé regresní scénáře.
A pokud se ukáže, že nástroj není třeba opustit, řekneme to. U rozsáhlé grid infrastruktury a týmu, který zná Selenium, může dávat smysl zůstat a přepracovat pouze architekturu nebo jazyk. Někdy stačí sadu opravit.
Co z toho máte
Sadu na aktivně udržovaném nástroji, u kterého je menší riziko problémů s novými verzemi prohlížečů a závislostí.
Zároveň lze omezit množství náhradních řešení a otevřít možnosti pro scénáře, které starý nástroj nepodporoval nebo je zbytečně komplikoval.
Další krok
Řekněte nám, na čem sada stojí a co vás při práci s ní dnes nejvíce zdržuje. Ozvěte se nám – posoudíme, zda se vyplatí přejít jinam, nebo zda vám stačí menší zásah.