🥇Unit testy v databáze — ako to robíme v Sportmastere, druhá časť

Prvá časť — tu.

Predstavte si situáciu. Pred vami je úloha vyvinúť novú funkciu. Máte podklady od svojich predchodcov. Ak predpokladáte, že nemáte žiadne morálne záväzky, ako by ste sa zachovali?

Najčastejšie sa všetky staré podklady zabúdajú a všetko začína odznova. Nikto nemá rád hrabanie sa v cudzom kóde, a ak je čas, prečo sa nevenovať vytvoreniu vlastného systému? To je typický prístup a v mnohých ohľadoch správny. Ale v našom projekte sme sa rozhodli inak. Základom budúceho systému automatického testovania sme postavili na podkladoch testov unit-testov na utPLSQL od predchodcov a potom sme išli pracovať v niekoľkých paralelných smeroch.

Obnova starých unit-testov. Pod obnovou rozumieme prispôsobenie testov súčasnému stavu systému lojality a prispôsobenie testov štandardom utPLSQL.
Riešenie problému porozumenia, aké konkrétne metódy a procesy máme pokryté automatickými testami. Musíme si buď túto informáciu uchovávať v hlave, alebo robiť závery na základe samotného kódu automatických testov. Preto sme sa rozhodli vytvoriť katalóg. Každému automatickému testu sme priradili jedinečný mnemonický kód, vytvorili popis a zaznamenali nastavenia (napríklad, v akých podmienkach by sa mal spustiť, alebo čo by sa malo stať, ak spustenie testu zlyhá). V podstate sme vyplnili metadata o automatických testoch a umiestnili sme ich do štandardných tabuliek schémy utPLSQL.
Definícia stratégie rozšírenia, t.j. výber funkcií, ktoré majú byť overené automatickými testami. Rozhodli sme sa zamerať na tri veci: nové vylepšenia systému, incidenty z produkcie a kľúčové procesy systému. Týmto spôsobom sa vyvíjame paralelne s vydaním, zabezpečujeme vyššiu jeho kvalitu, rozširujeme objem regresie a zabezpečujeme spoľahlivosť systému na kritických miestach. Prvým takýmto úzkym miestom sa stal proces rozdeľovania zliav a bonusov na účtenkach.
Samozrejme, zaoberali sme sa vývojom nových automatických testov. Jednou z prvých úloh po vydaní bolo vyhodnotenie výkonnosti preddefinovaných výberov systému vernostných programov. V našom projekte je blok pevne stanovených sql dotazov, ktoré vyberajú zákazníkov podľa podmienok. Napríklad získať zoznam všetkých zákazníkov, ktorých posledný nákup bol v konkrétnom meste, alebo zoznam zákazníkov, ktorých priemerná suma nákupu je vyššia ako stanovená hodnota. Napísaním automatických testov sme overili preddefinované výbery, zaznamenali referenčné parametre výkonnosti, a navyše sme vykonali aj záťažové testovanie.
Práca s automatickými testami by mala byť pohodlná. Najčastejšie sa vykonávajú dve akcie: spustenie automatických testov a vytvorenie testovacích dát. Tak sa v našom systéme objavili dva pomocné moduly: modul spustenia a modul generovania dát.
Modul spustenia je predstavený ako jedna univerzálna procedúra s jedným vstupným textovým parametrom. Ako parameter je možné odovzdať mnemo kód automatického testu, názov balíka, názov testu, nastavenie automatického testu alebo rezervované kľúčové slovo. Procedúra vyberá a spúšťa všetky automatické testy, ktoré splňujú podmienky.
Modul generovania dát je predstavený vo forme balíka, v ktorom pre každý objekt testovaného systému (tabuľka v databáze) bola vytvorená špeciálna procedúra, ktorá vkladá údaje. V tejto procedúre sú maximálne vyplnené prednastavené hodnoty, čo zabezpečuje vytvorenie objektov doslova jedným kliknutím. A pre pohodlné používanie boli vytvorené šablóny vytváraných dát. Napríklad, vytvoriť zákazníka určitého veku s testovacím telefónom a uskutočneným nákupom.
Automatické testy by sa mali spúšťať a pracovať v prijateľnom čase pre váš systém. Preto bol organizovaný každodenný nočný spúšť, po ktorom sa vytvára správa o výsledkoch a rozosiela sa celému vývojovému tímu prostredníctvom firemnej pošty. Po obnovení starých automatických testov a vytvorení nových celkový čas prevádzky predstavoval 30 minút. Takáto výkonnosť všetkých uspokojila, pretože spúšťanie prebiehalo mimo pracovného času.
Avšak optimalizácia rýchlosti práce si vyžiadala často extra úsilie. Aktualizácia vernostného systému sa uskutočňuje cez noc. V rámci jednej z verzií bolo potrebné vykonať naliehavé zmeny počas noci. Polhodinové čakanie na výsledky automatizovaných testov o tretej ráno neprinieslo šťastie zodpovednému za verziu (veľký pozdrav Alexejovi Vasyukovovi!), a nasledujúce ráno sme počuli veľa pochvalných slov smerom k nášmu systému. Nakoniec bol zavedený 5-minútový štandard na vykonávanie práce.
Na zrýchlenie výkonu sme využili dve metódy: automatizované testy sa začali spúšťať v troch paralelných prúdach, čo nám veľmi vyhovuje vzhľadom na architektúru nášho vernostného systému. Rozhodli sme sa tiež vzdať prístupu, pri ktorom automatizovaný test nevytvára vlastné testovacie údaje, ale snaží sa nájsť niečo vhodné v systéme. Po vykonaní zmien sa celkové časové nároky znížili na 3-4 minúty.
Projekt s automatizovanými testami je potrebné vedieť nasadiť na rôznych prostrediach. Na začiatku sme sa pokúsili napísať vlastné scriptovací súbory, ale čoskoro bolo jasné, že vlastný automatizovaný inštalátor je úplne strašný, a tak sme sa obrátili k priemyselným riešeniam. Vzhľadom na to, že v projekte je veľmi veľa priamo kódu (predovšetkým uchovávame kód automatizovaných testov) a veľmi málo údajov (hlavné údaje sú metadáta o automatizovaných testoch), implementácia Liquibase bola veľmi jednoduchá.
Je to databázu nezávislá knižnica s otvoreným zdrojovým kódom na sledovanie, správu a aplikáciu zmien v schéme databázy. Riadi sa prostredníctvom príkazového riadku alebo rámcov ako Apache Maven. Princíp fungovania Liquibase je pomerne jednoduchý. Máme usporiadaný projekt, ktorý sa skladá zo zmien alebo skriptov, ktoré je potrebné aplikovať na cieľový server, a kontrolné súbory, ktoré určujú, v akom poradí a s akými parametrami majú byť tieto zmeny nasadené.
Na úrovni databázového systému sa vytvára špeciálna tabuľka, v ktorej Liquibase uchováva log zmien. Každá zmena má vypočítaný hash, ktorý sa zakaždým porovnáva medzi projektom a stavom v databáze. Vďaka Liquibase ľahko aplikujeme zmeny našej systému na akýkoľvek kontúr. Automatizované testy sa teraz spúšťajú na testovacích a uvoľňovacích kontúroch, ako aj na kontajneroch (osobných kontúroch vývojárov).

Takže, poďme sa porozprávať o výsledkoch použitia nášho systému unit-testovania.

Samozrejme, predovšetkým sme presvedčení, že sme začali vyvíjať kvalitnejší softvér. Automatizované testy sa spúšťajú denne a pri uvoľnení nachádzajú desiatky chýb. A čo je zaujímavé, niektoré z týchto chýb sú len nepriamo spojené s funkčnosťou, ktorú sme skutočne chceli zmeniť. Máme veľké pochybnosti, že by tieto chyby boli nájdené manuálnym testovaním.
Tím získal presvedčenie, že konkrétna funkčnosť funguje správne... Predovšetkým sa to týka našich kritických procesov. Napríklad, za posledných šesť mesiacov sme nemali problémy s rozdeľovaním zliav a bonusov na účte, napriek uvoľňovacím zmenám, hoci v predchádzajúcich obdobiach sa chyby vyskytovali s určitou pravidelnosťou.
Podarilo sa nám skrátiť počet iterácií testovania. Vďaka tomu, že automatizované testy sú písané na nový funkčný modul, sa k analytikom a súčasne testerom dostáva kód vyššej kvality, pretože už bol overený.
Časť výsledkov automatizovaného testovania používajú vývojári. Napríklad, testovacie údaje na kontajneroch sa vytvárajú pomocou modulu generovania objektov.
Nie je zanedbateľné, že sa u nás vytvorilo "prijatie" systému automatizovaného testovania zo strany vývojárov. Existuje porozumenie, že to je dôležité a prínosné. A zo svojich skúseností môžem povedať, že to nie je tak. Automatizované testy je potrebné písať, je potrebné ich udržiavať a rozvíjať, analyzovať výsledky, a často sú časové náklady na to jednoducho neopodstatnené. Oveľa jednoduchšie je ísť na produkciu a tam riešiť problémy. U nás sa však vývojári stavajú do frontu a žiadajú o pokrytie ich funkčnosti automatizovanými testami.

Čo ďalej

Poďme sa porozprávať o plánoch rozvoja projektu automatizovaného testovania.

Samozrejme, pokiaľ je systém vernosti Sportmastera aktívny a naďalej sa vyvíja, môžeme takmer nekonečne rozvíjať aj automatizované testy. Preto hlavné zameranie rozvoja je rozšírenie pokrytia.

S narastajúcim počtom automatizovaných testov bude neustále rastie aj celkový čas ich vykonávania, a opäť sa budeme musieť vrátiť k otázke výkonu. Najpravdepodobnejšie bude riešením zvýšenie počtu paralelných vlákien.

Ale to sú zjavné cesty rozvoja. Ak hovoríme o niečom menej triviálnom, vyčleňme nasledujúce:

Aktuálne je správa automatizovaných testov realizovaná na úrovni DBMS, to znamená, že potrebujeme znalosti PL/SQL pre úspešnú prácu. Ak je to potrebné, môžeme spravovanie systému (napríklad vykonávanie spúšťaní alebo vytváranie metadát) preniesť na nejakú administrátorskú aplikáciu, využijúc Jenkins alebo niečo podobné.
Všetci majú radi kvantitatívne a kvalitatívne ukazovatele. Pre automatizované testovanie je takým univerzálnym ukazovateľom Code Coverage alebo metrika pokrytia kódu. Pomocou tohoto ukazovateľa môžeme určiť, aké percento kódu našej testovacej sústavy je pokryté automatizovanými testami. Od verzie 12.2 Oracle poskytuje možnosti na výpočet tejto metriky a navrhuje používať štandardný balík DBMS_PLSQL_CODE_COVERAGE.
Náš systém automatizovaného testovania má niečo vyše roka a možno je teraz ten správny čas na vyhodnotenie pokrytia. V mojom predchádzajúcom projekte (projekt nie je Sportmaster) to takto dopadlo. Po roku práce s automatizovanými testami vedenie zadalo úlohu zhodnotiť, aké percento kódu pokrývame. Pri pokrytí nad 1% by vedenie bolo šťastné. My, vývojári, sme očakávali výsledok okolo 10%. Pripojili sme code coverage, zmerali sme to a dostali 20%. V radosti sme sa vybrali za prémiou, ale ako sme za ňou išli a kam sme sa vybrali neskôr, to je úplne iný príbeh.
Automatizované testy môžu overovať vystavené webové služby. Oracle to bez problémov umožňuje, a my už viac nenarazíme na množstvo problémov.
A samozrejme, náš systém automatizovaného testovania je možné aplikovať na iný projekt. Naše riešenie je univerzálne a vyžaduje si len použitie Oracle. Počul som, že na iných projektoch Sportmasteru existuje záujem o automatizované testovanie a možno sa k nim vyberieme.

Zhrnutie

Zhrňme to. Na projekte vernostného systému v Sportmastere sa nám podarilo implementovať systém automatizovaného testovania. Jeho základom je riešenie utPLSQL od Stevena Feiershteina. Okolo utPLSQL je kód automatizovaných testov a pomocné vlastné moduly: modul spúšťania, modul generovania dát a ďalšie. Automatizované testy sa spúšťajú denne a, čo je najdôležitejšie, fungujú a prinášajú úžitok. Sme presvedčení, že sme začali vydávať softvér vyššej kvality. Získané riešenie je pritom univerzálne a môže byť voľne aplikované na akýkoľvek projekt, kde je potrebné zorganizovať automatizované testovanie na databáze Oracle.

P.S. Tento článok nie je príliš konkrétny: je tu veľa textu a takmer žiadne technické príklady. Ak je téma zaujímavá, sme pripravení pokračovať a vrátiť sa s pokračovaním, kde povieme, čo sa zmenilo za posledných šesť mesiacov a uvedieme príklady kódu.

Píšte komentáre, ak sú nejaké body, na ktoré by sme sa mali v budúcnosti zamerať, alebo otázky, ktoré potrebujú objasnenie.

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.