Určite sa vám už neraz stalo, že ste si z chuti ponadávali na pracovné nástroje, ktoré sú nevyhnutnou súčasťou vašej každodennej práce. Tak ako mäsiar potrebuje ostrý nôž, kuriér pojazdnú dodávku či murár kvalitnú maltu, aj vývojár automatizovaných testov potrebuje mať to pravé orechové – nástroj, ktorý správne sadne na testovaný objekt a dennú prácu.

Niežeby pôvodný nástroj našich „automatizérov“ neplnil svoju úlohu, práve naopak, pár rokov dozadu bol ideálnym riešením. Ale ako to už niekedy býva, plynúcimi rokmi sa z nástroja vytratila efektivita. V nasledujúcich riadkoch by sme vám radi sprostredkovali naše začiatky, ako aj samotný priebeh migrácie našej pôvodnej „backendovej“ test automatizácie založenej na Micro Focus UFT do aktuálne veľmi známeho a komunitou obľúbeného nástroja – do Cypressu.

INOVAČNÉ PIATKY DALI ZELENÚ NOVÉMU NÁSTROJU

Štartovacou čiarou pre Cypress sa stal formát tzv. inovačných piatkov. Prvý koncept testu navrhnutého v tomto nástroji vznikol práve na takomto workshope, ktorý sa na našom projekte organizuje pravidelne raz za štvrťrok. Témy sú zozbierané vopred, pričom zapojiť sa môže každý, a to vlastným nápadom či pridaním sa k už existujúcej myšlienke a skupine, ktorá potom túto ideu rozvíja a pracuje na prvotnom pilotnom riešení.

Niekoľkí ľudia zapojení do projektu považovali Cypress za vhodnú alternatívu už dlhší čas. Dokonca ho developeri jedného zo „Scrum“ tímov začali aj izolovane používať, no väčšina testerov stále používala pôvodný nástroj. Postupne k jednému tímu pribudli ďalšie štyri, takže nový nástroj získaval čoraz väčší priestor.

PROCES A DÔVODY VÝBERU

Migrácia bola špecifická a jedinečná v tom, že v nej boli zapojené iba tímy venujúce sa aplikačnej vrstve systému. Náš projekt je pomerne veľký a v rámci neho sa väčšina ľudí venuje funkčnému a integračnému testovaniu jednej alebo viacerých mikroservisov (Spring Boot). Preto bolo potrebné vybrať univerzálny nástroj určený pre test automatizáciu. A hoci je Cypress prezentovaný najmä ako UI nástroj, nechýbajú mu ani prvky, ktoré umožňujú pokryť celý procesný tok, a to od databázy cez REST servis, „messaging“, SOAP komunikáciu až po spomínanú webovú prezentačnú vrstvu.

Navyše, Node JS, v ktorom je Cypress osadený, poskytuje modularitu pomocou NPM, čo je verejný manažér balíčkov pre JavaScript poskytujúci širokú paletu rozšírení. Ako testerom aplikačnej vrstvy sa nám núkala možnosť „zneužitia“ jedného z unit test nástrojov našich developerov, no rozhodli sme sa udržať decentralizované nastavenie projektu. To v praxi znamená, že ako vývojári automatizovaných testov sme boli čiastočne oddelení, a to aj napriek úzkemu kontaktu s našimi tímami (najmä developermi).

PRÍPRAVA ZÁKLADNÝCH FUNKCIONALÍT

Pri príprave Cypressu na netypickú rolu nástroja na testovanie webových služieb sa objavilo už od začiatku niekoľko otázok, na ktoré sme potrebovali nájsť vhodné odpovede.

KOĽKO SEPARÁTNYCH PROJEKTOV POUŽIJEME?

V prípade, ak sa jedná o malú a jednoduchú aplikáciu, je riešenie veľmi jednoduché, a to jeden Cypress projekt na všetko. Naša situácia však bola odlišná. Nakoľko každý z mikroservisov predstavuje samostatnú aplikáciu s množstvom funkcionalít, mohol by nastať problém so zdieľaním kódu, ak by sme vytvorili osobitný Cypress projekt pre každý z nich. Navyše, práca by sa spomalila, pretože každý tím spravuje viacero mikroservisov, a tak by tester musel neustále prepínať projekty.

Uvažovali sme aj nad opačným prístupom, a to vytvoriť jeden veľký globálny repozitár so všetkými testami pre 20+ mikroservisov. Konečným riešením však bola stredná cesta. Aplikácie sme rozdelili do klastrov, ktoré dostali dedikovaný Cypress projekt. V praxi to teda vyzerá tak, že každý tím má jeden repozitár, pretože sa stará o skupinu „backend“ aplikácií, ktoré majú spoločného technického menovateľa.

AKO RIEŠIŤ REPORTY, KTORÉ CHCEME NIEKDE ULOŽIŤ A ARCHIVOVAŤ?

Ako test manažment nástroj sme používali ALM, ktorý je kompatibilný s UFT, avšak ťažko integrovateľný so Cypressom. Dočasne sme teda zvolili cestu pre vytváranie reportov pomocou knižnice Mochawesome, ktorá po exekúcii testov vygeneruje HTML report. Tie ukladáme na Gite spolu s testami v osobitnom priečinku a report neskôr pripojíme k danej user story pomocou linku.

IMPLEMENTOVAŤ CI/CD HNEĎ ALEBO NESKÔR?

V dnešnej dobe je integrácia automatizovaných testov do „CI/CD pipeline“ veľmi populárna, no napriek tomu sme sa rozhodli ju na našom projekte nateraz nepoužiť. Hlavným dôvodom je spôsob testovania kódu našimi developermi. Okrem unit testov tvoria aj tzv. systémové testy, ktoré sú integrované v „build pipeline“. Tie sú veľmi podobné našim funkčným testom, no v porovnaní s nimi používajú menšie množstvo testovacích scenárov. Preto sme sa rozhodli ďalšiu testovaciu vrstvu neaplikovať.

AKO PRISTUPOVAŤ K MYSQL DATABÁZAM?

Pre jednoduchý prístup sme použili NPM balíček “mysql”.

AKO VZÁJOMNE ZDIEĽAŤ URL ADRESU, PRIHLASOVACIE A PRÍSTUPOVÉ ÚDAJE?

Využili sme existujúci konfiguračný server, ktorý slúžil najmä Spring Boot aplikáciám. Pristupujeme k nemu  pomocou ďalšieho NPM balíčka (“cloud-config-server”), čím máme neustále k dispozícii všetky potrebné prístupové údaje, ktoré sú v prípade zmeny aktualizované našimi developermi.  

PROCES VZDELÁVANIA A MIGRÁCIA

Po vyriešení technických záležitostí sme začali so zdieľaním vedomostí a plánovaním migrácie. Proces vzdelávania a zdieľania know-how nám šiel veľmi dobre, a to aj napriek tomu, že sme dovtedy prakticky na 90 % využívali prostredie s minimálnym použitím kódu. Vývojári automatizovaných testov si na Cypress pomerne rýchlo zvykli. Plán migrácie bol však o čosi náročnejší. Už od začiatku sme tušili, že s takým množstvom testov nebude vykonanie migrácie rýchle a jednoduché, nakoľko je Cypress technologicky úplne odlišný nástroj. A tak nám neostávalo nič iné, ako začať plánovať postupnú manuálnu migráciu jedného testu po druhom. Čísla prekvapili všetkých. Testov bolo veľa, preto každý tím dostal priestor, aby optimalizoval množstvo tých svojich a odhadol čas migrácie. Na základe odhadu všetkých tímov sme sa rozhodli, že budeme migrovať postupne štvrťrok za štvrťrokom a popritom budeme vyvíjať aj nové testy.

Samotná migrácia prebehla plynulo a momentálne už UFT využívame len na to, aby sme z pôvodného testu získali potrebné informácie na vytvorenie nového už v Cypresse.

POHĽAD DO BUDÚCNOSTI

Postupom času sme zistili, že nie každé naše rozhodnutie bolo správne. Napríklad oddelením repozitárov sme spôsobili to, že každý vývojár automatizovaných testov sa uberá vlastnou implementáciou riešenia v Cypresse. Najdôležitejšie však je, že celková situácia je podstatne lepšia, ako bola v čase využívania pôvodného nástroja na automatizáciu testov. Cypress je omnoho efektívnejší a jeho najväčším prínosom je úspora času.

Autor: Jozef Kováč

sk_SKSlovenčina