🥇Unit testy v DB - jak to děláme ve Sportmasteru, část druhá

První část — zde.

Představte si situaci. Stojíte před úkolem vyvinout novou funkci. Máte nějaké materiály od svých předchůdců. Pokud předpokládáme, že nemáte žádné morální závazky, jak byste se zachovali?

Nejčastěji jsou všechny staré materiály zapomenuty a vše začíná znovu. Nikdo nemá rád prohrabování se v cizím kódu, a pokud máte čas, proč se nezaměřit na vytvoření vlastní systému? Toto je typický přístup, a do značné míry je správný. Ale v našem projektu jsme se rozhodli jinak. Základem budoucího systému automatického testování jsme postavili na materiálech o unit-testování na utPLSQL od předchůdců a poté jsme začali pracovat v několika paralelních směrech.

Obnova starých unit-testů. Pod obnovou se rozumí přizpůsobení testů současnému stavu systému loajality a přizpůsobení testů standardům utPLSQL.
Řešení problému s porozuměním, které konkrétně metody a procesy máme pokryté automatickými testy. Je třeba tuto informaci buď mít v hlavě, nebo vyvozovat závěry přímo na základě kódu automatických testů. Proto jsme se rozhodli vytvořit katalog. Každému automatickému testu jsme přiřadili unikátní mnemonický kód, vytvořili jsme popis a zaznamenali nastavení (např. v jakých podmínkách by měl být spuštěn, nebo co by se mělo stát, pokud spuštění testu neuspěje). V podstatě jsme vyplnili metadata o automatických testech a umístili tato metadata do standardních tabulek schématu utPLSQL.
Stanovení strategie rozšíření, tj. výběr funkcionality, která bude podléhat ověřování automatickými testy. Rozhodli jsme se zaměřit na tři věci: nové úpravy systému, incidenty z produkce a klíčové procesy systému. Tímto způsobem se vyvíjíme paralelně s vydáním, což zajišťuje jeho vyšší kvalitu, zároveň rozšiřujeme objem regresních testů a zajišťujeme spolehlivost systému v kritických místech. Prvním takovým úzkým místem byl proces rozdělování slev a bonusů podle účtu.
Samozřejmě jsme se pustili do vývoje nových automatických testů. Jedním z prvních úkolů při vydání byla evaluace výkonu předem definovaných výběrů věrnostního systému. V našem projektu máme blok pevných SQL dotazů, které vybírají zákazníky podle podmínek. Například získat seznam všech zákazníků, jejichž poslední nákup byl v konkrétním městě, nebo seznam zákazníků, jejichž průměrná částka nákupu je vyšší než určité hodnoty. Napsáním automatických testů jsme ověřili předem definované výběry, zaznamenali referenční hodnoty výkonu a navíc jsme provedli zátěžové testování.
Práce s automatickými testy by měla být pohodlná. Nejčastěji se provádějí dva úkony: spuštění automatických testů a vytvoření testovacích dat. Tak v našem systému vznikly dva pomocné moduly: modul pro spuštění a modul pro generování dat.
Modul pro spuštění je prezentován jako jedna univerzální procedura s jedním vstupním textovým parametrem. Jako parametr lze předávat mnemonický kód automatického testu, název balíčku, název testu, nastavení automatického testu nebo rezervované klíčové slovo. Procedura vybírá a spouští všechny automatické testy, které splňují podmínky.
Modul pro generování dat je prezentován jako balíček, ve kterém je pro každý objekt testovaného systému (tabulka v DB) vytvořena speciální procedura, která do ní vkládá data. V této proceduře jsou maximálně vyplněny výchozí hodnoty, což umožňuje vytváření objektů doslova jedním kliknutím. A pro usnadnění používání byly vytvořeny šablony vytvářených dat. Například vytvořit zákazníka určitého věku s testovacím telefonem a uskutečněným nákupem.
Automatické testy by měly být spouštěny a fungovat za rozumný čas pro váš systém. Proto byl organizován každodenní noční běh, na jehož základě se vytváří zpráva o výsledcích a rozesílá se celému vývojovému týmu prostřednictvím firemního e-mailu. Po obnovení starých automatických testů a vytvoření nových činil celkový čas běhu 30 minut. Taková výkonnost všechny uspokojovala, protože spuštění probíhalo mimo pracovní dobu.
Na optimalizaci rychlosti práce bylo třeba zapracovat. Aktualizace systému loajality se provádí v produkci v noci. V rámci jedné z releasů bylo nutné v noci urgentně provést změny. Půlhodinové čekání na výsledky automatizovaných testů ve tři hodiny ráno neudělalo odpovědného za release šťastným (srdečný pozdrav Alexejovi Vasyukovovi!), a následující ráno bylo na naši systém vyřčeno mnoho pozitivních slov. Ale po výsledcích byla nastavena pětiminutová norma na práci.
Pro urychlení výkonu jsme využili dvě metody: automatizované testy začaly běžet ve třech paralelních vláknech, což je velmi pohodlné díky architektuře našeho systému loajality. A vzdali jsme se přístupu, kdy automatizovaný test nevytváří testovací data sám, ale snaží se najít v systému něco vhodného. Po provedení změn se celkový čas práce zkrátil na 3-4 minuty.
Projekt s automatizovanými testy je třeba umět nasadit na různých prostředích. Na začátku jsme se pokusili napsat vlastní batiky, ale ukázalo se, že ručně napsaná automatizovaná instalace je totální katastrofa, a obrátili jsme se k průmyslovým řešením. Vzhledem k tomu, že v projektu je velmi mnoho přímo kódu (především uchováváme kód automatizovaných testů) a velmi málo dat (hlavními daty jsou metadata o automatizovaných testech), bylo implementace Liquibase do projektu velmi jednoduché.
Je to nezávislá na databázi knihovna s otevřeným zdrojovým kódem pro sledování, správu a aplikaci změn schématu databáze. Řídí se prostřednictvím příkazového řádku nebo rámců typu Apache Maven. Princip fungování Liquibase je dost jednoduchý. Máme uspořádaný projekt, který se skládá ze změn nebo skriptů, které je třeba aplikovat na cílový server, a řídících souborů, které určují, v jakém pořadí a s jakými parametry je třeba tyto změny instalovat.
Na úrovni DB se vytváří speciální tabulka, ve které Liquibase uchovává log změn. Každá změna má vypočítaný hash, který se každým pokusem porovnává mezi projektem a stavem v databázi. Díky Liquibase snadno aplikuje změny našeho systému na jakýkoli kontur. Automatizované testy se nyní spouští na testovacích a produktových konturách, stejně jako na kontejnerech (osobních konturách vývojářů).

Takže, pojďme si promluvit o výsledcích aplikace našeho systému unit-testování.

Samozřejmě, v první řadě jsme přesvědčeni, že jsme začali vyvíjet kvalitnější software. Automatizované testy se spouští denně a po každém vydání odhalují desítky chyb. Navíc část těchto chyb je pouze nepřímo spojena s funkcionalitou, kterou jsme skutečně chtěli změnit. Jsou vážné pochybnosti, že by tyto chyby byly nalezeny manuálním testováním.
Tým získal jistotu, že konkrétní funkcionalita funguje správně... Především se to týká našich kritických procesů. Například za poslední půlrok jsme měli problémy s distribucí slev a bonusů na účtenkách, přestože docházelo k pravidelným změnám, zatímco v předchozích obdobích se s touto záležitostí občas objevovaly chyby.
Podařilo se nám zkrátit počet iterací testování. Díky tomu, že se automatizované testy píší pro novou funkcionalitu, se k analytikům a zároveň testerům dostává kvalitnější kód, protože už byl ověřen.
Část výstupů automatizovaného testování využívají vývojáři. Například testovací data na kontejnerech se vytvářejí pomocí modulu pro generaci objektů.
Není bez zajímavosti, že se nám podařilo vytvořit akceptaci systému automatizovaného testování ze strany vývojářů. Existuje pochopení, že je to důležité a užitečné. A ze svých zkušeností mohu říci, že tomu tak zdaleka není. Automatizované testy je potřeba psát, udržovat a rozvíjet, analyzovat výsledky, a často jsou tyto časové náklady prostě neúměrné. Je mnohem jednodušší jít na produkci a tam řešit problémy. U nás mají vývojáři tendenci se shromažďovat a žádat o pokrytí jejich funkcionality automatizovanými testy.

Co dál

Pojďme si promluvit o plánech rozvoje projektu automatizovaného testování.

Bezpochyby, dokud systém věrnosti Sportmasteru žije a dále se vyvíjí, můžeme také nekonečně rozvíjet automatizované testy. Hlavním směrem vývoje je tedy rozšíření pokrytí.

S nárůstem počtu automatizovaných testů se nevyhnutelně zvýší celkový čas jejich běhu, a budeme muset znovu čelit otázce výkonnosti. Řešením pravděpodobně bude zvýšení počtu paralelních vláken.

Ale to jsou zřejmé cesty rozvoje. Pokud jde o něco méně triviálního, vyberme následující:

Nyní je správa automatizovaných testů prováděna na úrovni DBMS, tj. potřebné jsou znalosti PL/SQL pro úspěšnou práci. V případě potřeby lze správu systému (například spuštění nebo vytváření metadat) outsourcovat do nějaké administrativní aplikace, použijeme-li Jenkins nebo něco podobného.
Všichni mají rádi kvantitativní a kvalitativní ukazatele. Pro automatizované testování je takovým univerzálním ukazatelem Code Coverage, neboli metrika pokrytí kódu. Pomocí tohoto ukazatele můžeme určit, jaké procento kódu naše testované systémy je pokryto automatickými testy. Od verze 12.2 poskytuje Oracle možnosti pro výpočet této metriky a doporučuje používat standardní balík DBMS_PLSQL_CODE_COVERAGE.
Naší systému automatizovaných testů je něco málo přes rok a pravděpodobně nyní je ten správný čas na hodnocení pokrytí. V mém předchozím projektu (projekt není Sportmaster) se to také stalo. Po roce práce na automatických testech management zadal úkol vyhodnotit, jaké procento kódu pokrýváme. Při pokrytí více než 1% by byl management šťastný. My, vývojáři, očekávali výsledek kolem 10%. Přidali jsme code coverage, změříli jsme to a dostali 20%. Radostí jsme šli za prémií, ale jak jsme za ní šli a kam jsme se poté vydali, to je úplně jiný příběh.
Automatizované testy mohou ověřovat vystavené webové služby. Oracle to zcela umožňuje, a my se už nesetkáme s mnoha problémy.
A samozřejmě, náš systém automatizovaného testování může být použit i v jiném projektu. Naše řešení je univerzální a vyžaduje pouze použití Oracle. Slyšel jsem, že na jiných projektech Sportmasteru je zájem o automatizované testování, a možná se k nim vydáme.

Závěry

Shrňme to. Na projektu systému loajality v Sportmasteru se nám podařilo implementovat systém automatizovaného testování. Základem je řešení utPLSQL od Stevena Feierstaina. Kolem utPLSQL je umístěn kód automatizovaných testů a pomocné vlastní moduly: modul spuštění, modul generace dat a další. Automatizované testy se každý den spouští a, co je nejdůležitější, fungují a přinášejí užitek. Jsme přesvědčeni, že jsme začali vydávat software vyšší kvality. Přitom získané řešení je univerzální a může být volně použito na jakémkoli projektu, kde je třeba organizovat automatizované testování na DB Oracle.

P.S. Tento článek není příliš konkrétní: je zde hodně textu a téměř chybějí technické příklady. Pokud je téma zajímavé, jsme připraveni na něj navázat a vrátit se s pokračováním, kde řekneme, co se změnilo za posledních šest měsíců a uvedeme příklady kódu.

Pište komentáře, pokud jsou nějaké body, na které bychom se měli v budoucnu zaměřit, nebo otázky, které potřebují osvětlení.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.