Jednotkové testy v DBMS - ako to robíme v Sportmaster, druhá časť

Prvá časť - tu.

Predstavte si situáciu. Stojíte pred úlohou vyvinúť novú funkcionalitu. Máte skúsenosti od svojich predchodcov. Čo by ste urobili za predpokladu, že nemáte žiadne morálne záväzky?

Najčastejšie sa na všetok starý vývoj zabudne a všetko sa začína odznova. Nikto sa rád nehrabe v cudzom kóde a ak máte čas, prečo nezačať vytvárať vlastný systém? Toto je typický prístup av mnohých ohľadoch správny. Ale v našom projekte sme postupovali inak. Budúci automatizovaný testovací systém sme založili na vývoji jednotkových testov na utPLSQL od našich predchodcov a potom sme začali pracovať niekoľkými paralelnými smermi.

1. Obnovenie starých testov jednotiek. Recovery znamená prispôsobenie testov existujúcemu stavu vernostného systému a prispôsobenie testov štandardom utPLSQL.
2. Riešenie problému s pochopením, a čo presne, aké metódy a procesy, sme pokryli autotestami. Tieto informácie si musíte buď nechať v hlave, alebo vyvodiť závery priamo na základe kódexu autotestov. Preto sme sa rozhodli vytvoriť katalóg. Každému autotestu sme priradili jedinečný mnemotechnický kód, vytvorili popis a opravili nastavenia (napríklad, za akých podmienok sa má spustiť alebo čo sa má stať, ak test zlyhá). V podstate sme vyplnili metadáta o autotestoch a umiestnili tieto metadáta do štandardných tabuliek schémy utPLSQL.
3. Definícia stratégie expanzie, t.j. výber funkcionality, ktorá podlieha overeniu autotestami. Rozhodli sme sa venovať pozornosť trom veciam: novým vylepšeniam systému, incidentom z výroby a kľúčovým procesom systému. Paralelne s vydaním teda vyvíjame, čím zabezpečujeme jeho vyššiu kvalitu, súčasne rozširujeme rozsah regresie a zabezpečujeme spoľahlivosť systému na kritických miestach. Prvým takýmto úzkym hrdlom bol proces rozdeľovania zliav a bonusov šekom.
4. Prirodzene sme začali s vývojom nových autotestov. Jednou z prvých úloh vydania bolo vyhodnotenie výkonnosti preddefinovaných vzoriek vernostného systému. Náš projekt má blok pevne stanovených SQL dotazov, ktoré vyberajú klientov podľa podmienok. Získajte napríklad 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 presahuje určitú hodnotu. Po napísaní autotestov sme skontrolovali preddefinované vzorky, zafixovali výkonnostné parametre benchmarku a navyše sme dostali záťažové testovanie.
5. Práca s autotestami by mala byť pohodlná. Dve najbežnejšie akcie sú spustenie autotestov a generovanie testovacích údajov. Takto sa v našom systéme objavili dva pomocné moduly: spúšťací modul a modul generovania údajov.

   Spúšťač je reprezentovaný ako jedna generická procedúra s jedným vstupným textovým parametrom. Ako parameter môžete zadať mnemotechnický kód autotestu, názov balíka, názov testu, nastavenie automatického testu alebo vyhradené kľúčové slovo. Procedúra vyberie a spustí všetky autotesty, ktoré spĺňajú podmienky.

   Modul generovania dát je prezentovaný ako balík, v ktorom je pre každý objekt testovaného systému (tabuľka v databáze) vytvorená špeciálna procedúra, ktorá tam vkladá dáta. V tomto postupe sú predvolené hodnoty vyplnené na maximum, čo zaisťuje vytváranie objektov doslova kliknutím prsta. A pre jednoduchosť používania boli vytvorené šablóny pre generované dáta. Vytvorte si napríklad klienta určitého veku s testovacím telefónom a dokončeným nákupom.

6. Autotesty by sa mali spustiť a spustiť v primeranom čase pre váš systém. Preto bol zorganizovaný denný nočný launch, na základe ktorého sa vygeneruje report o výsledkoch, ktorý sa pošle celému vývojovému tímu firemnou poštou. Po obnovení starých autotestov a vytvorení nových bol celkový čas behu 30 minút. Takýto výkon vyhovoval všetkým, keďže spustenie prebiehalo v mimopracovných hodinách.

   Museli sme ale popracovať na optimalizácii rýchlosti práce. Vernostný systém výroby sa aktualizuje v noci. V rámci jedného z vydaní sme museli v noci urgentne urobiť zmeny. Polhodinové čakanie na výsledky autotestov o tretej ráno nepotešilo osobu zodpovednú za prepustenie (srdečný pozdrav Alexejovi Vasyukovovi!) A na druhý deň ráno zaznelo na náš systém veľa teplých slov. Ale v dôsledku toho bol stanovený 5-minútový štandard na prácu.

   Na zrýchlenie výkonu sme použili dve metódy: začali sme spúšťať autotesty v troch paralelných vláknach, keďže je to veľmi výhodné vzhľadom na architektúru nášho vernostného systému. A opustili sme prístup, keď autotest nevytvára testovacie dáta pre seba, ale snaží sa nájsť niečo vhodné v systéme. Po vykonaní zmien sa celkový prevádzkový čas skrátil na 3-4 minúty.

7. Projekt s autotestami by sa mal dať nasadiť na rôzne stojany. Na začiatku cesty boli pokusy o napísanie vlastných dávkových súborov, no ukázalo sa, že vlastnoručne napísaná automatizovaná inštalácia je hotová hrôza a obrátili sme sa na priemyselné riešenia. Vzhľadom na to, že projekt má priamo veľa kódu (v prvom rade ukladáme kód autotestov) a veľmi málo údajov (hlavnými údajmi sú metadáta o autotestoch), ukázalo sa, že je veľmi jednoduché ho integrovať do Projekt Liquibase.

   Je to open source databáza nezávislá knižnica na sledovanie, správu a aplikáciu zmien databázových schém. Spravované cez príkazový riadok alebo frameworky ako Apache Maven. Princíp fungovania Liquibase je pomerne jednoduchý. Máme určitým spôsobom organizovaný projekt, ktorý pozostáva zo zmien alebo skriptov, ktoré je potrebné nahrať na cieľový server, a riadiacich súborov, ktoré určujú, v akom poradí a s akými parametrami sa tieto zmeny majú nainštalovať.

   Na úrovni DBMS je vytvorená špeciálna tabuľka, do ktorej Liquibase ukladá rollback log. Každá zmena má vypočítaný hash, ktorý sa zakaždým porovnáva medzi projektom a stavom v databáze. Vďaka Liquibase môžeme jednoducho zaviesť zmeny v našom systéme na akýkoľvek okruh. Autotesty sa teraz spúšťajú na testovacích a uvoľňovacích slučkách, ako aj na kontajneroch (osobné slučky vývojárov).

Poďme sa teda porozprávať o výsledkoch aplikácie nášho systému testovania jednotiek.

1. Samozrejme, v prvom rade sme presvedčení, že sme začali vyvíjať lepší softvér. Autotesty prebiehajú denne a v každom vydaní nájdu desiatky chýb. Navyše, niektoré z týchto chýb súvisia len nepriamo s funkcionalitou, ktorú sme skutočne chceli zmeniť. Existujú silné pochybnosti, že tieto chyby boli nájdené manuálnym testovaním.
2. Tím získal istotu, že konkrétna funkcionalita funguje správne... V prvom rade ide o naše kritické procesy. Napríklad za posledných šesť mesiacov sme nemali problémy s distribúciou zliav a bonusov šekom, a to napriek zmenám vykonaným pri každom vydaní, hoci v predchádzajúcich obdobiach sa chyby vyskytli s určitou frekvenciou
3. Podarilo sa nám znížiť počet testovacích iterácií. Vzhľadom na to, že autotesty sú písané pre nové funkcie, analytici a testeri na čiastočný úväzok získavajú kód vyššej kvality, pretože už je to overené.
4. Časť vývoja automatizovaného testovania využívajú vývojári. Napríklad testovacie údaje o kontajneroch sa vytvárajú pomocou modulu generovania objektov.
5. Je dôležité, že sme vyvinuli „akceptovanie“ automatizovaného testovacieho systému vývojármi. Existuje pochopenie, že je to dôležité a užitočné. A z vlastnej skúsenosti môžem povedať, že to tak ani zďaleka nie je. Autotesty treba napísať, treba ich udržiavať a rozvíjať, analyzovať výsledky a často sa tieto časové náklady jednoducho nevyplatia. Je oveľa jednoduchšie ísť do výroby a riešiť problémy tam. U nás sa vývojári zoraďujú a žiadajú pokryť svoju funkcionalitu autotestami.

čo ďalej

Povedzme si niečo o plánoch rozvoja projektu automatizovaného testovania.

Samozrejme, pokiaľ je vernostný systém Sportmaster živý a neustále sa vyvíja, možno autotesty tiež rozvíjať takmer donekonečna. Hlavným smerom vývoja je preto rozšírenie oblasti pokrytia.

S pribúdajúcim počtom autotestov bude celkový čas ich práce neustále narastať a opäť sa budeme musieť vrátiť k otázke výkonu. S najväčšou pravdepodobnosťou bude riešením zvýšenie počtu paralelných vlákien.

Ale to sú jasné spôsoby rozvoja. Ak hovoríme o niečom netriviálnejšom, zdôrazníme nasledovné:

1. Teraz sú autotesty riadené na úrovni DBMS, t.j. pre úspešnú prácu je potrebná znalosť PL/SQL. Ak je to potrebné, správu systému (napríklad spustenie alebo vytváranie metadát) môže vykonať nejaký admin panel pomocou Jenkins alebo niečoho podobného.
2. Každý má rád kvantitatívne a kvalitatívne ukazovatele. Pre automatické testovanie je takýmto univerzálnym indikátorom Code Coverage alebo metrika pokrytia kódu. Pomocou tohto indikátora môžeme určiť, aké percento kódu nášho testovaného systému je pokryté autotestami. Od verzie 12.2 poskytuje Oracle možnosť vypočítať túto metriku a navrhuje použiť štandardný balík DBMS_PLSQL_CODE_COVERAGE.

   Náš systém autotestu je len niečo vyše roka starý a možno je čas vyhodnotiť pokrytie. V mojom poslednom projekte (projekt nie Sportmaster) sa to stalo. Rok po práci na autotestoch si vedenie dalo za úlohu posúdiť, koľko percent kódu sme pokryli. S viac ako 1% pokrytím by bol manažment spokojný. My, vývojári, sme očakávali výsledok okolo 10 %. Pokazili sme pokrytie kódom, zmerali sme to a dostali 20 %. Na oslavu sme išli po cenu, ale ako sme si po ňu išli a kam sme išli neskôr, je úplne iný príbeh.

3. Autotesty môžu testovať vystavené webové služby. Oracle vám to umožňuje a už sa nestretneme s množstvom problémov.
4. A náš automatizovaný testovací systém je, samozrejme, možné aplikovať aj na iný projekt. Riešenie, ktoré sme dostali, je univerzálne a vyžaduje len použitie Oracle. Počul som, že je záujem o automatizované testovanie na iných projektoch Sportmaster a možno do nich pôjdeme.

Závery

Poďme si to zrekapitulovať. Na projekte vernostného systému v Sportmaster sa nám podarilo implementovať automatizovaný testovací systém. Jeho základom je riešenie utPLSQL od Stephena Feuersteina. Okolo utPLSQL je kód pre autotesty a pomocné samostatne písané moduly: spúšťač, modul na generovanie údajov a ďalšie. Autotesty prebiehajú denne a hlavne fungujú a prinášajú úžitok. Sme presvedčení, že sme začali vydávať softvér vyššej kvality. Výsledné riešenie je zároveň univerzálne a možno ho voľne aplikovať na akýkoľvek projekt, kde je potrebné organizovať automatizované testovanie na Oracle DBMS.

PS Tento článok sa ukázal ako málo konkrétny: je tam veľa textu a prakticky žiadne technické príklady. Ak je téma globálne zaujímavá, tak sme pripravení v nej pokračovať a vrátiť sa s pokračovaním, kde vám povieme, čo sa za posledných šesť mesiacov zmenilo a uvedieme príklady kódu.

Napíšte komentáre, ak existujú body, ktoré by ste mali v budúcnosti zdôrazniť, alebo otázky, ktoré si vyžadujú zverejnenie.

Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prihlásiť saProsím.

Napíšeme o tom viac?

• Áno, samozrejme

• Nie ďakujem

Hlasovalo 12 užívateľov. 4 používatelia sa zdržali hlasovania.

Zdroj: hab.com