🥇Unit-tests i DB — hvordan vi gør det i Sportmaster, del to

Første del — her.

Forestil dig situationen. Du står over for opgaven at udvikle ny funktionalitet. Du har nogle materialer fra dine forgængere. Hvis vi antager, at du ikke har nogen moralske forpligtelser, hvordan ville du så handle?

Ofte bliver alle gamle materialer glemt, og alt begynder forfra. Ingen elsker at rode i andres kode, og hvis tiden er til det, hvorfor så ikke bruge den på at skabe sit eget system? Dette er en typisk tilgang og i mange tilfælde en korrekt en. Men i vores projekt gjorde vi det anderledes. Vi lagde grundlaget for det fremtidige automatiserede testsystem på materialer fra unit-tests i utPLSQL fra vores forgængere, og derefter gik vi i gang med at arbejde i flere parallelle retninger.

Genskabelse af gamle unit-tests. Med genskabelse menes tilpasning af testene til den nuværende tilstand af loyalitetssystemet og tilpasning af testene til standarderne for utPLSQL.
Løsningen på problemet med forståelsen af, hvilke metoder og processer der er dækket af automatiserede tests. Man skal enten holde denne information i hovedet eller drage konklusioner baseret direkte på koden til de automatiserede tests. Derfor besluttede vi at danne et katalog. Hver automatiseret test fik tildelt en unik mnemonic kode, vi dannede en beskrivelse og dokumenterede indstillingerne (for eksempel, under hvilke betingelser den skal køres, eller hvad der skal ske, hvis testens kørsel mislykkes). I bund og grund udfyldte vi metadata om de automatiserede tests og placerede disse metadata i standardtabellerne i utPLSQL-schemaet.
Definition af udvidelsesstrategi, dvs. valg af funktionalitet, der skal testes af automatiserede tests. Vi besluttede at fokusere på tre ting: de nye forbedringer af systemet, hændelser fra produktionen og de centrale processer i systemet. På den måde udvikler vi os parallelt med udgivelsen, sikrer højere kvalitet i den, samtidig med at vi udvider omfanget af regressionstests og sikrer systemets pålidelighed på kritiske områder. Det første sådanne flaskehals var processen til fordeling af rabatter og bonusser på kvitteringen.
Naturligvis tog vi fat på at udvikle nye automatiserede tests. En af de første opgaver efter udgivelsen var at vurdere ydeevnen af de foruddefinerede udtræk i lojalitetssystemet. I vores projekt er der en sektion med faste SQL-forespørgsler, der udvælger kunder baseret på specifikationer. For eksempel at få en liste over alle kunder, hvis seneste køb var i en bestemt by, eller en liste over kunder, hvis gennemsnitlige køb er over en bestemt værdi. Efter at have skrevet automatiserede tests, kontrollerede vi de foruddefinerede udtræk, fastsatte referenceparametre for ydeevnen, og vi fik desuden mulighed for belastningstestning.
Arbejdet med automatiserede tests skal være brugervenligt. De to mest udførte handlinger er: at starte automatiserede tests og oprette testdata. Derfor blev der oprettet to hjælpemoduler i vores system: et startmodul og et datagenereringsmodul.
Startmodulet er udformet som en universel procedure med en enkelt tekstparameter som input. Som parameter kan man angive mnemonic-koden for den automatiserede test, navnet på pakken, navnet på testen, indstillingerne for den automatiserede test eller et reserveret nøgleord. Proceduren udvælger og starter alle automatiserede tests, der opfylder betingelserne.
Datagenereringsmodulet er præsenteret i form af en pakke, hvor der for hvert objekt i det testede system (tabel i databasen) er oprettet en særlig procedure, der indsætter data der. I denne procedure er de standardværdier maksimalt udfyldt, hvilket muliggør oprettelsen af objekter bogstaveligt talt med et fingerknips. For brugervenlighed er der blevet oprettet skabeloner til de oprettede data. For eksempel at oprette en kunde af en bestemt alder med et testtelefonnummer og et gennemført køb.
Automatiske tests skal startes og fungere inden for acceptabel tid for dit system. Derfor blev der arrangeret et dagligt natkørsel, hvis resultater danner en rapport, der sendes til hele udviklingsteamet via virksomhedens e-mail. Efter at have genoprettet gamle automatiserede tests og oprettet nye, var den samlede køretid 30 minutter. En sådan ydeevne tilfredsstillede alle, da kørslen fandt sted uden for arbejdstiden.
Men måtte arbejde på at optimere hastigheden. Opdateringen af loyalitetssystemet finder sted om natten. Under et af frigivelserne måtte der laves hurtige ændringer om natten. Den halvtime lange ventetid på resultaterne fra autotests i tre om natten gjorde ikke den ansvarlige for udgivelsen glad (et varmt hej til Alexey Vasyukov!), men næste morgen blev der sagt mange pæne ord om vores system. Resultatet var, at der blev fastsat en 5-minutters norm for arbejdet.
For at øge ydeevnen anvendte vi to metoder: autotests blev kørt i tre parallelle processer, hvilket er meget praktisk på grund af arkitekturen i vores loyalitetssystem. Vi har også opgivet tilgangen, hvor autotests ikke laver testdata til sig selv, men forsøger at finde noget passende i systemet. Efter ændringerne blev den samlede behandlingstid reduceret til 3-4 minutter.
Projektet med autotests skal kunne implementeres på forskellige miljøer. I starten var der forsøg på at skrive egne batch-filer, men det blev klart, at en skræddersyet automatiseret installation var en komplet katastrofe, og vi tiltrak os opmærksomhed mod industrielle løsninger. Da projektet indeholder meget kode (først og fremmest opbevarer vi koden til autotests) og meget lidt data (de vigtigste data er metadata om autotests), var det meget enkelt at implementere Liquibase i projektet.
Det er et databasen-uafhængigt biblioteksprogram med åben kilde, der bruges til at spore, administrere og anvende ændringer i databaseskemaer. Det styres via kommandolinjen eller rammer som Apache Maven. Princippet for Liquibase er ret enkelt. Vi har et projekt, der er organiseret på en bestemt måde, som består af ændringer eller scripts, der skal anvendes på den målserver, samt styringsfiler, der definerer, i hvilken rækkefølge og med hvilke parametre de ændringer skal anvendes.
På databasesystemniveau oprettes der et specielt tabel, hvor Liquibase opbevarer loggen over ændringer. Hver ændring har en beregnet hash, som konstant sammenlignes mellem projektet og tilstanden i databasen. Takket være Liquibase kan vi let anvende ændringer i vores system på enhver kontur. Automatisk testkørsel foregår nu på test- og produktionskonturer samt på containere (personlige konturer for udviklere).

Lad os tale om resultaterne af anvendelsen af vores enhedstestsystem.

Selvfølgelig er vi først og fremmest overbeviste om, at vi er begyndt at udvikle mere kvalitetsbevidst software. Automatisk test køres dagligt og ved hver release finder den dusinvis af fejl. Desuden er nogle af disse fejl kun indirekte relateret til den funktionalitet, vi faktisk ønskede at ændre. Der er store tvivl om, at disse fejl ville være blevet fundet ved manuel testning.
Teamet har fået selvtillid til, at den specifikke funktionalitet fungerer korrekt... Dette gælder især vores kritiske processer. For eksempel har vi i løbet af det sidste halve år ikke haft problemer med distribution af rabatter og bonusser i kvitteringen, på trods af ændringer ved hver release, selvom der i tidligere perioder med jævne mellemrum opstod fejl.
Vi har formået at reducere antallet af testiterations. Takket være at de automatiske tests skrives for den nye funktionalitet, modtager analytikerne og testerne kode af højere kvalitet, da det allerede er blevet testet.
Nogle af resultaterne fra automatiseret testning anvendes af udviklerne. For eksempel oprettes testdata på containere ved hjælp af en modul til objektgenerering.
Det er vigtigt, at vi har fået accept af systemet for automatiseret testning fra udviklerne. Der er en forståelse for, at det er vigtigt og nyttigt. Men ud fra min egen erfaring kan jeg sige, at dette slet ikke er tilfældet. Automatiske tests skal skrives, de skal vedligeholdes og udvikles, resultaterne skal analyseres, og ofte er disse tidsinvesteringer simpelthen ikke det værd. Det er langt nemmere at gå til produktionen og håndtere problemerne der. Vores udviklere står i kø og beder om at få deres funktionalitet dækket af automatiserede tests.

vil være udsolgt

Lad os tale om udviklingsplanerne for projektet for automatiseret testning.

Uden tvivl, så længe Sportmaster's loyalitetsprogram er aktivt og fortsætter med at udvikle sig, kan vi næsten uendeligt videreudvikle autotests. Derfor er den primære udviklingsretning at udvide dækningen.

Efterhånden som antallet af autotests stiger, vil den samlede køretid også stigende, og vi må igen vende tilbage til spørgsmålet om ydeevne. Sandsynligvis vil løsningen være at øge antallet af parallelle tråde.

Men det er åbenlyse udviklingsveje. Hvis vi skal tale om noget mere utraditionelt, så fremhæver vi følgende:

I øjeblikket håndteres autotests på niveauet for databasesystemet, dvs. der kræves kendskab til PL/SQL for at arbejde succesfuldt. Efter behov kan administrationen af systemet (f.eks. udførelse af kørsel eller oprettelse af metadata) outsources til et admin-panel, som f.eks. Jenkins eller noget lignende.
Alle elsker kvantitative og kvalitative målinger. For automatiseret test er en sådan universel måling Code Coverage eller kode dække metrics. Ved hjælp af denne måling kan vi bestemme, hvilken procentdel af koden i vores testede system dækkes af autotests. Fra version 12.2 tilbyder Oracle muligheder for beregning af denne måling og anbefaler at bruge standardpakken DBMS_PLSQL_CODE_COVERAGE.
Vores autotestsystem er lidt over et år gammelt, og måske er det nu det rette tidspunkt at vurdere dækningen. I mit tidligere projekt (som ikke var Sportmaster) viste det sig at være tilfældet. Et år efter arbejdet med autotests satte ledelsen opgaven med at vurdere, hvor stor en del af koden vi dækker. Ved en dækning på over 1% ville ledelsen være tilfreds. Vi, udviklerne, forventede et resultat på omkring 10%. Vi tilknyttede code coverage, målte og fik 20%. I glæden skyndte vi os for at få en bonus, men hvordan vi fik den og hvor vi gik hen senere, er en helt anden historie.
Autotests kan kontrollere de udstillede webtjenester. Oracle giver os helt klart mulighed for at gøre dette, og vi vil ikke længere støde på en række problemer.
Og selvfølgelig kan vores automatiserede testsystem anvendes i et andet projekt. Den løsning, vi har udviklet, er universel og kræver kun brugen af Oracle. Jeg har hørt, at der er interesse for automatiseret testning i andre projekter hos Sportmaster, og måske skal vi tage over til dem.

Konklusioner

Lad os opsummere. I projektet med loyalitetssystemet i Sportmaster har vi formået at implementere et automatiseret testsystem. Grundlaget for det er løsningen utPLSQL fra Steven Feuerstein. Omkring utPLSQL er koden til autostests og hjælpemodulerne: startmodul, datagenereringsmodul og andre. Autotests køres dagligt, og vigtigst af alt, de fungerer og giver værdi. Vi er overbeviste om, at vi er begyndt at levere software af højere kvalitet. Den løsning, vi har udviklet, er universel og kan frit anvendes i ethvert projekt, hvor der er behov for at organisere automatiseret testning på Oracle DB.

P.S. Denne artikel blev ikke særlig konkret: der er meget tekst og næsten ingen tekniske eksempler. Hvis emnet overordnet set er interessant, er vi klar til at fortsætte og vende tilbage med et opslag, hvor vi fortæller, hvad der er ændret i de seneste seks måneder og medbringer kodeeksempler.

Skriv kommentarer, hvis der er punkter, vi skal fokusere på i fremtiden, eller spørgsmål, der kræver uddybning.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.