Unit testy v DBMS - jak to děláme ve Sportmaster, část druhá

První díl - zde.

Představte si situaci. Stojíte před úkolem vyvinout novou funkcionalitu. Máte zkušenosti od svých předchůdců. Co byste dělali za předpokladu, že nemáte žádné morální závazky?

Nejčastěji je veškerý starý vývoj zapomenut a vše začíná znovu. Nikdo se rád nehrabe v cizím kódu, a pokud máte čas, proč nezačít vytvářet svůj vlastní systém? To je typický přístup a v mnoha ohledech správný. Ale v našem projektu jsme postupovali jinak. Budoucí automatizovaný testovací systém jsme založili na vývoji unit testů na utPLSQL od našich předchůdců a poté jsme začali pracovat několika paralelními směry.

1. Obnovení starých jednotkových testů. Recovery znamená přizpůsobení testů stávajícímu stavu věrnostního systému a přizpůsobení testů standardům utPLSQL.
2. Řešení problému s porozuměním, a co přesně, jaké metody a procesy, jsme pokryli autotesty. Tyto informace musíte buď uchovávat v hlavě, nebo vyvozovat závěry přímo na základě kódu autotestů. Proto jsme se rozhodli vytvořit katalog. Každému autotestu jsme přiřadili jedinečný mnemotechnický kód, vytvořili popis a opravili nastavení (například za jakých podmínek se má spustit nebo co se má stát, když se testovací běh nezdaří). V podstatě jsme vyplnili metadata o autotestech a umístili tato metadata do standardních tabulek schématu utPLSQL.
3. Definice strategie expanze, tzn. výběr funkčnosti, která podléhá ověření autotesty. Rozhodli jsme se věnovat pozornost třem věcem: novým vylepšením systému, incidentům z výroby a klíčovým procesům systému. Souběžně s vydáním tedy vyvíjíme, zajišťujeme jeho vyšší kvalitu, současně rozšiřujeme rozsah regrese a zajišťujeme spolehlivost systému na kritických místech. Prvním takovým úzkým hrdlem byl proces rozdělování slev a bonusů šekem.
4. Samozřejmě jsme začali vyvíjet nové autotesty. Jedním z prvních úkolů vydání bylo vyhodnocení výkonu předdefinovaných vzorků věrnostního systému. Náš projekt má blok pevně fixovaných SQL dotazů, které vybírají klienty podle podmínek. Získejte například 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 nad určitou hodnotou. Po písemných autotestech jsme zkontrolovali předdefinované vzorky, stanovili výkonnostní parametry benchmarku a navíc jsme dostali zátěžové testování.
5. Práce s autotesty by měla být pohodlná. Dvě nejběžnější akce jsou spuštění autotestů a generování testovacích dat. Takto se v našem systému objevily dva pomocné moduly: spouštěcí modul a modul pro generování dat.

   Spouštěč je reprezentován jako jedna generická procedura s jedním vstupním textovým parametrem. Jako parametr můžete předat mnemotechnický kód autotestu, název balíčku, název testu, nastavení autotestu nebo vyhrazené klíčové slovo. Procedura vybere a spustí všechny autotesty, které splňují podmínky.

   Modul generování dat je prezentován jako balíček, ve kterém je pro každý objekt testovaného systému (tabulka v databázi) vytvořena speciální procedura, která tam vkládá data. V tomto postupu jsou výchozí hodnoty naplněny na maximum, což zajišťuje vytváření objektů doslova kliknutím prstu. A pro snadné použití byly vytvořeny šablony pro generovaná data. Vytvořte si například klienta určitého věku s testovacím telefonem a dokončeným nákupem.

6. Autotesty by měly běžet a běžet v době přiměřené pro váš systém. Proto bylo zorganizováno každodenní noční spuštění, na jehož základě je vygenerována zpráva o výsledcích a zaslána celému vývojovému týmu firemní poštou. Po obnovení starých autotestů a vytvoření nových byla celková doba běhu 30 minut. Takové vystoupení vyhovovalo všem, protože spuštění probíhalo mimo pracovní dobu.

   Museli jsme ale zapracovat na optimalizaci rychlosti práce. Produkční věrnostní systém je aktualizován v noci. V rámci jednoho z vydání jsme museli v noci urychleně provést změny. Půlhodinové čekání na výsledky autotestů ve tři hodiny ráno nepotěšilo osobu zodpovědnou za propuštění (srdečné pozdravy Alexeji Vasjukovovi!), a druhý den ráno zazněla na náš systém spousta vřelých slov. Ale ve výsledku byl stanoven 5minutový standard na práci.

   Pro urychlení výkonu jsme použili dvě metody: začali jsme spouštět autotesty ve třech paralelních vláknech, protože to je velmi výhodné vzhledem k architektuře našeho věrnostního systému. A opustili jsme přístup, kdy autotest nevytváří testovací data pro sebe, ale snaží se najít něco vhodného v systému. Po provedení změn se celková doba provozu zkrátila na 3-4 minuty.

7. Projekt s autotesty by měl být možné nasadit na různé stojany. Na začátku cesty byly pokusy napsat vlastní dávkové soubory, ale ukázalo se, že vlastnoručně psaná automatizovaná instalace je hotová hrůza a obrátili jsme se k průmyslovým řešením. Vzhledem k tomu, že projekt má přímo mnoho kódu (především ukládáme kód autotestů) a velmi málo dat (hlavními daty jsou metadata o autotestech), ukázalo se, že je velmi snadné jej integrovat do Projekt Liquibase.

   Jedná se o open source databázi nezávislou knihovnu pro sledování, správu a aplikaci změn databázového schématu. Spravováno pomocí příkazového řádku nebo frameworků jako Apache Maven. Princip fungování Liquibase je poměrně jednoduchý. Máme určitým způsobem organizovaný projekt, který se skládá ze změn nebo skriptů, které je třeba nahrát na cílový server, a kontrolních souborů, které určují, v jakém pořadí a s jakými parametry se tyto změny mají nainstalovat.

   Na úrovni DBMS je vytvořena speciální tabulka, do které Liquibase ukládá rollback log. Každá změna má vypočítaný hash, který se pokaždé porovnává mezi projektem a stavem v databázi. Díky Liquibase můžeme snadno zavést změny v našem systému na jakýkoli okruh. Autotesty nyní probíhají na testovacích a uvolňovacích okruzích, stejně jako na kontejnerech (osobní vývojářské okruhy).

Pojďme si tedy promluvit o výsledcích aplikace našeho systému testování jednotek.

1. Samozřejmě v první řadě jsme přesvědčeni, že jsme začali vyvíjet lepší software. Autotesty probíhají denně a najdou desítky chyb v každém vydání. Navíc některé z těchto chyb souvisejí pouze nepřímo s funkčností, kterou jsme skutečně chtěli změnit. Existují silné pochybnosti, že tyto chyby byly nalezeny ručním testováním.
2. 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ích šest měsíců jsme neměli problémy s distribucí slev a bonusů šekem, a to i přes změny provedené v každém vydání, i když v předchozích obdobích se chyby vyskytovaly s určitou frekvencí
3. Podařilo se nám snížit počet testovacích iterací. Vzhledem k tomu, že autotesty jsou psány pro nové funkce, analytici a testeři na částečný úvazek získávají kód vyšší kvality, protože už je to ověřeno.
4. Část vývoje automatizovaného testování využívají vývojáři. Například testovací data o kontejnerech se vytvářejí pomocí modulu pro generování objektů.
5. Je důležité, že jsme vyvinuli „akceptaci“ systému automatizovaného testování vývojáři. Existuje pochopení, že je to důležité a užitečné. A z vlastní zkušenosti mohu říci, že tomu tak zdaleka není. Autotesty je třeba psát, udržovat a rozvíjet, analyzovat výsledky a často se tyto časové náklady prostě nevyplatí. Je mnohem jednodušší jít do výroby a řešit problémy tam. U nás se vývojáři staví do fronty a žádají pokrýt svoji funkcionalitu autotesty.

Co je další

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

Samozřejmě, dokud je věrnostní systém Sportmaster živý a neustále se vyvíjí, lze také autotesty vyvíjet téměř donekonečna. Hlavním směrem vývoje je proto rozšíření oblasti pokrytí.

S přibývajícím počtem autotestů se bude neustále prodlužovat celková doba jejich práce a opět se budeme muset vrátit k otázce výkonu. S největší pravděpodobností bude řešením zvýšení počtu paralelních vláken.

Ale to jsou zřejmé způsoby rozvoje. Pokud mluvíme o něčem netriviálnějším, upozorníme na následující:

1. Nyní jsou autotesty spravovány na úrovni DBMS, tzn. Pro úspěšnou práci je nutná znalost PL/SQL. V případě potřeby může být správa systému (například spouštění nebo vytváření metadat) odstraněna pomocí nějakého admin panelu pomocí Jenkins nebo něčeho podobného.
2. Každý má rád kvantitativní a kvalitativní ukazatele. Pro automatické testování je takovým univerzálním indikátorem Code Coverage neboli metrika pokrytí kódu. Pomocí tohoto indikátoru můžeme určit, jaké procento kódu našeho testovaného systému je pokryto autotesty. Počínaje verzí 12.2 poskytuje Oracle možnost vypočítat tuto metriku a navrhuje použití standardního balíčku DBMS_PLSQL_CODE_COVERAGE.

   Náš systém autotestu je jen něco málo přes rok starý a možná je čas vyhodnotit pokrytí. V mém posledním projektu (projekt ne od Sportmaster) se to stalo. Rok po práci na autotestech si vedení dalo za úkol posoudit, jaké procento kódu jsme pokryli. S více než 1% pokrytím by bylo vedení spokojeno. My, vývojáři, jsme očekávali výsledek kolem 10 %. Podělali jsme pokrytí kódem, změřili jsme to a dostali 20 %. Na oslavu jsme šli pro cenu, ale jak jsme si pro ni šli a kam jsme šli později, je úplně jiný příběh.

3. Autotesty mohou testovat vystavené webové služby. Oracle vám to umožňuje a s řadou problémů se již nesetkáme.
4. A náš automatizovaný testovací systém lze samozřejmě aplikovat i na jiný projekt. Řešení, které jsme obdrželi, je univerzální a vyžaduje pouze použití Oracle. Slyšel jsem, že je zájem o automatizované testování na dalších projektech Sportmaster a možná do nich půjdeme.

Závěry

Pojďme si to zrekapitulovat. Na projektu věrnostního systému ve Sportmaster se nám podařilo implementovat automatizovaný testovací systém. Jeho základem je řešení utPLSQL od Stephena Feuersteina. Kolem utPLSQL je kód pro autotesty a pomocné samostatně psané moduly: spouštěč, modul pro generování dat a další. Autotesty běží denně a hlavně fungují a prospívají. Jsme přesvědčeni, že jsme začali vydávat software vyšší kvality. Výsledné řešení je zároveň univerzální a lze jej libovolně aplikovat na jakýkoli projekt, kde je potřeba organizovat automatizované testování na Oracle DBMS.

PS Tento článek se ukázal jako málo konkrétní: je tam hodně textu a prakticky žádné technické příklady. Pokud je téma globálně zajímavé, tak jsme připraveni v něm pokračovat a vrátit se s pokračováním, kde vám řekneme, co se za posledních šest měsíců změnilo a uvedeme příklady kódu.

Napište komentáře, pokud existují body, které by měly být v budoucnu zdůrazněny, nebo otázky, které vyžadují zveřejnění.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Napíšeme si o tom víc?

• Ano, samozřejmě

• Ne, díky

Hlasovalo 12 uživatelů. 4 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com