🥇Teste unitare în SGBD — cum facem asta la Sportmaster, partea a doua

Prima parte — aici.

Imaginați-vă o situație. Aveți sarcina de a dezvolta o nouă funcționalitate. Aveți la dispoziție munca celor care v-au precedat. Dacă presupunem că nu aveți obligații morale, cum ați proceda?

Cel mai adesea, toate vechile lucrări cad în uitare și totul începe de la zero. Nimeni nu iubește să sape prin codul altora, iar dacă aveți timp, de ce să nu vă ocupați de crearea propriului sistem? Aceasta este o abordare tipică și în mare parte corectă. Dar în proiectul nostru am procedat diferit. Am bazat viitorul sistem de testare automată pe lucrările anterioare privind testele unitare în utPLSQL ale predecesorilor noștri, apoi am început să lucrăm în mai multe direcții paralele.

Restaurarea vechilor teste unitare. Prin restaurare se înțelege adaptarea testelor la starea actuală a sistemului de loialitate și adaptarea testelor la standardele utPLSQL.
Soluționarea problemei de înțelegere a ceea ce anume, ce metode și procese sunt acoperite de testele automate. Trebuie fie să păstrăm aceste informații în minte, fie să facem concluzii pe baza codului testelor automate. De aceea, am decis să formăm un catalog. Fiecare test automat a primit un cod mnemotehnic unic, am creat o descriere și am înregistrat setările (de exemplu, în ce condiții ar trebui să fie rulat sau ce ar trebui să se întâmple dacă testul eșuează). Practic, ne-am completat metadatele despre testele automate și le-am plasat în tabele standard ale schemei utPLSQL.
Definirea strategiei de extindere, adică alegerea funcționalităților care urmează să fie verificate de testele automate. Am decis să ne concentrăm pe trei aspecte: îmbunătățirile noi ale sistemului, incidentele din producție și procesele cheie ale sistemului. Astfel, ne dezvoltăm în paralel cu lansarea, asigurând o calitate mai înaltă a acesteia, extinzând în același timp volumul regresiei și asigurând fiabilitatea sistemului în locurile critice. Prima astfel de potecă a fost procesul de distribuire a discounturilor și bonusurilor pe bon.
În mod evident, ne-am pus pe dezvoltarea de noi teste automate. Una dintre primele sarcini de lansare a fost evaluarea performanței selecțiilor predefinite ale sistemului de loialitate. În proiectul nostru, există un bloc de interogări SQL fixe care aleg clienții pe diverse criterii. De exemplu, obținerea unei liste cu toți clienții ale căror achiziții recente au fost efectuate într-un oraș specific, sau a clienților a căror valoare medie a achiziției depășește o anumită sumă. Scriind teste automate, am verificat selecțiile predefinite, am fixat parametrii de referință pentru performanță, iar suplimentar am realizat teste de stres.
Lucrul cu teste automate trebuie să fie confortabil. Cele mai frecvente două acțiuni sunt: lansarea testelor automate și crearea de date de test. Astfel, în sistemul nostru au apărut două module auxiliare: modulul de lansare și modulul de generare a datelor.
Modulul de lansare este prezentat sub forma unei proceduri universale cu un singur parametru textual de intrare. Ca parametru, se poate transmite mnemonic al testului automat, numele pachetului, numele testului, configurația testului automat sau un cuvânt cheie rezervat. Procedura selectează și lansează toate testele automate care îndeplinesc condițiile.
Modulul de generare a datelor este prezentat sub forma unui pachet, în care pentru fiecare obiect al sistemului testat (tabel din baza de date) a fost creată o procedură specială care inserează date în acel tabel. Această procedură completează valorile implicite la maximum, ceea ce permite crearea de obiecte cu un simplu clic. Și pentru a spori confortul utilizării, au fost create șabloane pentru datele generate. De exemplu, crearea unui client de o anumită vârstă cu un număr de telefon de test și o achiziție efectuată.
Teste automate trebuie să fie lansate și să funcționeze într-un timp acceptabil pentru sistemul dumneavoastră. De aceea, a fost organizat un program zilnic de lansare nocturnă, iar rezultatele sunt compilate într-un raport care este trimis întregii echipe de dezvoltare prin e-mail corporativ. După restaurarea testelor automate anterioare și crearea unor teste noi, timpul total de execuție a fost de 30 de minute. Performanța similară a fost satisfăcătoare pentru toți, deoarece lansarea avea loc în afara orelor de lucru.
Însă optimizarea vitezei de lucru a necesitat o atenție specială. Actualizarea sistemului de loialitate în producție se face noaptea. În cadrul uneia dintre lansări, a fost necesară efectuarea urgentă a unor modificări în timpul nopții. O așteptare de o jumătate de oră pentru rezultatele testelor automate la trei dimineața nu l-a făcut pe cel responsabil de lansare foarte fericit (un salut călduros lui Alexei Vasiukov!), iar dimineața, în direcția sistemului nostru s-au spus multe cuvinte frumoase. Dar, în final, a fost stabilit un standard de 5 minute pentru funcționare.
Pentru a accelera performanța, am folosit două metode: testele automate au început să fie executate în trei fluxuri paralele, ceea ce este foarte convenabil datorită arhitecturii sistemului nostru de loialitate. De asemenea, am renunțat la abordarea în care testul automat nu își creează date de testare pentru sine, ci încearcă să găsească ceva potrivit în sistem. După efectuarea modificărilor, timpul total de lucru s-a redus la 3-4 minute.
Proiectul cu teste automate trebuie să poată fi desfășurat pe diverse standuri. La începutul călătoriei, au existat încercări de a scrie propriile scripturi batch, dar a devenit clar că o instalare automatizată făcută în casă este o adevărată tragedie, așa că ne-am îndreptat spre soluții comerciale. Având în vedere că proiectul conține foarte mult cod (în primul rând, stocăm codul testelor automate) și foarte puține date (datele principale fiind metadatele despre teste), implementarea Liquibase în proiect s-a dovedit a fi foarte simplă.
Este o bibliotecă independentă de baza de date, cu sursă deschisă, pentru monitorizarea, gestionarea și aplicarea modificărilor schemei bazei de date. Se gestionează prin intermediul liniei de comandă sau al cadrelor precum Apache Maven. Principiul de funcționare al Liquibase este destul de simplu. Avem un proiect organizat într-un anumit mod, format din modificări sau scripturi care trebuie aplicate pe serverul țintă, și fișiere de control care definesc în ce ordine și cu ce parametri trebuie aplicate aceste modificări.
La nivelul SGBD-ului, se creează un tabel special în care Liquibase stochează jurnalul modificărilor. Fiecare modificare are un hash calculat, care este comparat de fiecare dată între proiect și starea din baza de date. Datorită Liquibase, aplicăm ușor modificările sistemului nostru pe orice mediu. Testele automate sunt acum rulate în medii de testare și de lansare, precum și pe containere (mediile personale ale dezvoltatorilor).

Așadar, haideți să discutăm despre rezultatele aplicării sistemului nostru de teste unitare.

Desigur, în primul rând, suntem convinși că am început să dezvoltăm software de calitate mai bună. Testele automate rulează zilnic și la fiecare lansare găsesc zeci de erori. O parte din aceste erori sunt doar indirect legate de funcționalitatea pe care am vrut cu adevărat să o schimbăm. Există mari îndoieli că aceste erori ar fi fost descoperite prin testare manuală.
Echipa a căpătat încredere că funcționalitatea specifică funcționează corect... Acest lucru se referă, în primul rând, la procesele noastre critice. De exemplu, în ultimele șase luni, nu am avut probleme cu distribuția reducerilor și bonusurilor pe chitanță, în ciuda modificărilor la fiecare lansare, deși în perioadele anterioare, aceste erori apăreau cu o anumită regularitate.
Am reușit să reducem numărul de iterații de testare. Datorită faptului că testele automate sunt scrise pentru funcționalitatea nouă, analizele și, în același timp, testerii primesc cod de o calitate superioară, deoarece a fost deja verificat.
O parte din realizările testării automate sunt folosite de dezvoltatori. De exemplu, datele de testare pe containere sunt create cu ajutorul modulului de generare a obiectelor.
Este important să menționăm că am dezvoltat o "acceptare" a sistemului de teste automate din partea dezvoltatorilor. Există o înțelegere că acest lucru este important și util. Din experiența mea pot spune că nu este deloc așa. Testele automate trebuie scrise, susținute și dezvoltate, iar rezultatele trebuie analizate, iar adesea aceste eforturi temporale pur și simplu nu merită. Este mult mai simplu să mergi pe producție și să rezolvi problemele de acolo. La noi, dezvoltatorii se așează la rând și cer să le acoperim funcționalitatea cu teste automate.

Ce urmează

Haideți să discutăm despre planurile de dezvoltare a proiectului de testare automată.

Desigur, atâta timp cât sistemul de loialitate al Sportmaster este activ și continuă să se dezvolte, putem, de asemenea, dezvolta practic nelimitat testele automate. Prin urmare, direcția principală de dezvoltare este extinderea zonei de acoperire.

Pe măsură ce numărul testelor automate crește, timpul total de execuție va crește constant, iar noi va trebui din nou să revenim la problema performanței. Cel mai probabil, soluția va consta în creșterea numărului de fluxuri paralele.

Dar acestea sunt căi evidente de dezvoltare. Dacă vorbim despre ceva mai neobișnuit, să evidențiem următoarele:

În prezent, gestionarea testelor automate se face la nivel de SGBD, adică este nevoie de cunoștințe PL/SQL pentru o muncă de succes. Dacă este necesar, gestionarea sistemului (de exemplu, lansarea sau crearea de metadate) poate fi externalizată cu un panou de administrare, folosind Jenkins sau un instrument similar.
Toată lumea iubește indicatorii cantitativi și calitativi. Pentru testarea automată, un astfel de indicator universal este Code Coverage sau metrica acoperirii codului. Prin acest indicator putem determina ce procent din codul sistemului nostru testat este acoperit de testele automate. Începând cu versiunea 12.2, Oracle oferă posibilități pentru calcularea acestei metrici și sugerează utilizarea pachetului standard DBMS_PLSQL_CODE_COVERAGE.
Sistemul nostru de testare automată are puțin peste un an și, poate, acum este momentul potrivit pentru a evalua acoperirea. În trecutul meu proiect (care nu este al Sportmaster), a fost exact așa. După un an de muncă asupra testelor automate, conducerea a pus problema de a evalua ce procent din cod acoperim. Cu o acoperire de peste 1%, conducerea ar fi fost fericită. Noi, dezvoltatorii, ne așteptam la un rezultat de aproximativ 10%. Am implementat codul de acoperire, am măsurat și am obținut 20%. Cu bucurie, am mers să cerem o primă, dar cum am făcut acest lucru și unde ne-am îndreptat după, este o cu totul altă poveste.
Testele automate pot verifica serviciile web expuse. Oracle permite acest lucru fără probleme, iar noi nu ne mai întâlnim cu o serie de probleme.
Și, bineînțeles, sistemul nostru de testare automată poate fi aplicat și în alt proiect. Soluția pe care am dezvoltat-o este universală și necesită doar utilizarea Oracle. Am auzit că există un interes pentru testarea automată în alte proiecte ale Sportmaster și, posibil, ne vom îndrepta către ei.

Conclusions

Să resumăm. Pe proiectul sistemului de loialitate la Sportmaster, am reușit să implementăm un sistem de testare automată. Baza acestuia este soluția utPLSQL de la Steven Feuerstein. În jurul utPLSQL se află codul testelor automate și modulele auxiliare personalizate: modul de execuție, modul de generare a datelor și altele. Testele automate sunt rulate zilnic și, ceea ce este cel mai important, funcționează și aduc beneficii. Suntem convinși că am început să livrăm software de o calitate superioară. În același timp, soluția obținută este universală și poate fi aplicată liber în orice proiect unde este necesară organizarea testării automate pe SGBD Oracle.

P.S. Acest articol nu a fost foarte specific: avem mult text și practic lipsesc exemplele tehnice. Dacă interesul pentru subiect este global, suntem pregătiți să continuăm și să revenim cu o continuare, unde vom povesti despre ce s-a schimbat în ultimele șase luni și vom aduce exemple de cod.

Scrieți comentarii dacă există aspecte la care ar trebui să facem accent în viitor sau întrebări care necesită clarificare.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.