Test di unità in un DBMS - cumu si facemu in Sportmaster, a seconda parte

prima parte - ccà.

Imagine a situazione. Avete affruntatu u compitu di sviluppà una nova funziunalità. Avete sviluppi da i vostri predecessori. Se assumemu chì ùn avete micca obligazioni murali, chì faria?

A maiò spessu, tutti i vechji sviluppi sò scurdati è tuttu principia di novu. Nimu ùn li piace à scavà in u codice di l'altru, ma s'è vo avete tempu, perchè ùn principià micca à creà u vostru propiu sistema? Questu hè un approcciu tipicu, è hè largamente currettu. Ma in u nostru prughjettu avemu fattu male. Basatu u futuru sistema di teste automaticu nantu à i sviluppi in teste unità nantu à utPLSQL da i nostri predecessori, è dopu andò à travaglià in parechje direzzione parallele.

1. Ripristina vechji teste di unità. A ricuperazione significa adattà e teste à u statu esistenti di u sistema di fidelizazione è adattà e teste à i normi utPLSQL.
2. Risolviri un prublema cù una capiscitura di ciò chì esattamente, chì metudi è prucessi sò cuparti cù autotests. Avete da tene sta infurmazione in u vostru capu, o tirà cunclusioni basatu direttamente nantu à u codice autotest. Dunque, avemu decisu di creà un catalogu. Avemu assignatu un codice mnemonicu unicu à ogni autotest, creatu una descrizzione è paràmetri arregistrati (per esempiu, in quali cundizioni deve esse lanciatu, o ciò chì deve succede se u lanciu di prova falla). Essenzialmente, avemu populatu i metadati nantu à l'autotest è pusatu quelli metadati in tabelle standard di schema utPLSQL.
3. Definisce a strategia di espansione, i.e. selezzione di funziunalità chì hè sottumessu à verificazione da teste automatizati. Avemu decisu di attentu à trè cose: novi migliuramentu di u sistema, incidenti di produzzione è prucessi chjave di u sistema. Cusì, simu sviluppati in parallelu cù a liberazione, assicurendu a so qualità più alta, espansione simultaneamente u scopu di regressione è assicurendu a fiducia di u sistema in i lochi critichi. U primu collu di bottiglia era u prucessu di distribuzione di sconti è bonus nantu à un cuntrollu.
4. Naturalmente, avemu cuminciatu à sviluppà novi autotests. Unu di i primi compiti di liberazione era di valutà a prestazione di campioni predefiniti di u sistema di fidelizazione. U nostru prughjettu hà un bloccu di dumande SQL rigidamente fissate chì selezziunate i clienti basati nantu à e cundizioni. Per esempiu, uttene una lista di tutti i clienti chì l'ultima compra hè stata in una cità specifica, o una lista di i clienti chì a quantità media di compra hè sopra à un certu valore. Dopu avè scrittu autotesti, avemu verificatu campioni predefiniti, parametri di rendiment di benchmark registrati, è in più avemu avutu teste di carica.
5. U travagliu cù l'autotest deve esse convenientu. I dui azzioni più cumuni sò eseguisce autotests è creanu dati di teste. Hè cusì chì dui moduli ausiliari apparsu in u nostru sistema: un modulu di lanciamentu è un modulu di generazione di dati.

   U lanciatore hè rapprisintatu cum'è una prucedura universale cù un paràmetru di input di testu. Cum'è un paràmetru, pudete passà u codice mnemonicu di l'autotest, u nome di u pacchettu, u nome di a prova, l'autotest setting, o una keyword riservata. A prucedura selezziunà è eseguisce tutti l'autotests chì soddisfanu e cundizioni.

   U modulu di generazione di dati hè prisentatu in a forma di un pacchettu in quale per ogni ughjettu di u sistema in prova (una tavola in a basa di dati), hè stata creata una prucedura speciale chì inserisce dati quì. In questa prucedura, i valori predeterminati sò pienu quant'è pussibule, chì assicura a creazione di l'uggetti littiralmenti à u clicu di un dettu. È per facilità d'utilizazione, i mudelli per i dati generati sò stati creati. Per esempiu, crea un cliente di una certa età cù un telefunu di prova è una compra cumpleta.

6. L'autotest deve principià è curriri in un tempu chì hè accettatu per u vostru sistema. Per quessa, un lanciu di notte di ghjornu hè statu urganizatu, basatu annantu à i risultati di quale un rapportu nantu à i risultati hè generatu è mandatu à tutta a squadra di sviluppu via mail corporativu. Dopu a restaurazione di i vechji autotests è a creazione di novi, u tempu di operazione tutale era di 30 minuti. Sta prestazione cunvene à tutti, postu chì u lanciu hà fattu fora di l'ore di travagliu.

   Ma avemu avutu à travaglià per ottimisà a vitezza di u travagliu. U sistema di fidelizazione in a produzzione hè aghjurnatu di notte. Comu parte di una di e versioni, avemu avutu à fà cambiamenti urgenti di notte. Aspittendu una meza ora per i risultati di l'autotest à trè ore di a matina ùn hà micca fattu a persona rispunsevuli di a liberazione felice (saluti ardenti à Alexey Vasyukov!), è a matina dopu, parechje parolle gentile sò state dite versu u nostru sistema. Ma in u risultatu, un standard di 5 minuti per u travagliu hè statu stabilitu.

   Per accelerà u rendiment, avemu usatu dui metudi: l'autotests cuminciaru à curriri in trè fili paralleli, furtunatamente questu hè assai còmuda per l'architettura di u nostru sistema di fideltà. E avemu abbandunatu l'approcciu induve l'autotest ùn crea micca dati di prova per ellu stessu, ma prova di truvà qualcosa adattatu in u sistema. Dopu avè fattu i cambiamenti, u tempu di operazione tutale hè stata ridutta à 3-4 minuti.

7. Un prughjettu cù teste automatiche deve esse capace di esse implementatu in diversi stands. À u principiu di u nostru viaghju, ci sò stati tentativi di scrive i nostri fugliali batch, ma hè diventatu chjaru chì una stallazione autumàtica scritta da sè stessu era un orrore cumpletu, è avemu vultatu versu suluzioni industriali. A causa di u fattu chì u prughjettu cuntene assai codice direttu (prima di tuttu, avemu guardatu u codice di l'autotest) è assai pocu dati (i dati principali sò metadata nantu à l'autotest), l'implementazione in u prughjettu Liquibase hè stata assai simplice. .

   Hè una libreria open-source, indipendente da a basa di dati per u seguimentu, a gestione è l'esercitu di i cambiamenti di schema di basa di dati. Managed via a linea di cummanda o frameworks cum'è Apache Maven. U principiu di funziunamentu di Liquibase hè abbastanza sèmplice. Avemu un prughjettu urganizatu in un certu modu, chì hè custituitu di cambiamenti o scripts chì deve esse rializatu à u servitore di destinazione, è i schedarii di cuntrollu chì determinanu in quale sequenza è cù quale paràmetri questi cambiamenti devenu esse installati.

   À u livellu DBMS, una tavula speciale hè creata in quale Liquibase guarda u logu di rollover. Ogni cambiamentu hà un hash calculatu, chì hè paragunatu ogni volta trà u prugettu è u statu in a basa di dati. Grazie à Liquibase, pudemu facilmente lancià cambiamenti à u nostru sistema à qualsiasi circuitu. L'autotests sò avà lanciati nantu à i circuiti di prova è di liberazione, è ancu in cuntenituri (circuiti persunali di sviluppatori).

Dunque, parlemu di i risultati di l'usu di u nostru sistema di teste di unità.

1. Di sicuru, prima di tuttu, simu cunvinti chì avemu principiatu à sviluppà un software megliu. Autotests sò lanciati ogni ghjornu è decine d'errori sò truvati ogni liberazione. Inoltre, alcuni di questi errori sò solu indiretti in relazione cù e funziunalità chì vulemu veramente cambià. Ci sò seri dubbii chì sti errori sò stati truvati da testi manuali.
2. A squadra hà avà cunfidenza chì a funziunalità specifica funziona bè ... Prima di tuttu, questu cuncerna i nostri prucessi critichi. Per esempiu, in l'ultimi sei mesi ùn avemu micca avutu prublemi cù a distribuzione di sconti è bonus nantu à i ricevuti, malgradu i cambiamenti di liberazione, anche se in i periodi precedenti l'errori sò accaduti cù una certa frequenza.
3. Avemu riesciutu à riduce u numeru di iterazioni di teste. A causa di u fattu chì l'autotests sò scritti per una nova funziunalità, l'analisti è i teste à part-time ricevenu codice di qualità più altu, perchè hè digià verificatu.
4. Alcuni di i sviluppi in teste automatizati sò usati da i sviluppatori. Per esempiu, i dati di teste nantu à i cuntenituri sò creati cù u modulu di generazione d'ughjettu.
5. Hè impurtante chì avemu sviluppatu una "accettazione" di u sistema di teste automatizatu da parte di i sviluppatori. Ci hè un capiscenu chì questu hè impurtante è utile. Ma da a mo propria sperienza possu dì chì questu hè luntanu da u casu. L'autotest deve esse scrittu, deve esse supportatu è sviluppatu, i risultati anu da analizà, è spessu questi costi di tempu ùn sò micca solu a pena. Hè assai più faciule d'andà à a produzzione è di trattà i prublemi quì. Quì, i sviluppatori si mettenu in fila è ci dumandanu di copre a so funziunalità cù l'autotest.

Chì vene

Parlemu di i piani di sviluppu per u prughjettu di teste automatizatu.

Di sicuru, finu à chì u sistema di fidelizazione di Sportmaster hè vivu è cuntinueghja à sviluppà, hè ancu pussibule di sviluppà autotests quasi senza fine. Per quessa, a direzzione principale di u sviluppu hè espansione l'area di copertura.

Quandu u numeru di autotests aumenta, u so tempu di operazione tutale aumenterà constantemente, è avemu da turnà à u prublema di u rendiment. A più prubabile, a suluzione serà di aumentà u numeru di filamenti paralleli.

Ma questi sò modi evidenti di sviluppu. Se parlemu di qualcosa di più micca triviale, mettemu in risaltu i seguenti:

1. Attualmente, a gestione di l'autotest hè realizatu à u livellu DBMS, i.e. A cunniscenza di PL / SQL hè necessaria per u travagliu successu. Se necessariu, a gestione di u sistema (per esempiu, lanciazione o creazione di metadati), pudete creà un tipu di pannellu amministratore cù Jenkins o qualcosa simili.
2. Tutti amanu indicatori quantitativi è qualitativi. Per a prova automatizata, un tali indicatore universale hè Code Coverage o metric coverage code. Utilizendu stu indicatore, pudemu determinà quale percentuale di u codice di u nostru sistema in prova hè cupartu da l'autotest. Partendu da a versione 12.2, Oracle furnisce a capacità di calculà sta metrica è offre l'usu di u pacchettu standard DBMS_PLSQL_CODE_COVERAGE.

   U nostru sistema di autotest hè pocu più di un annu è forse avà hè u tempu di valutà a nostra cobertura. In u mo ultimu prughjettu (micca un prughjettu Sportmaster) hè ciò chì hè accadutu. Un annu dopu à travaglià nantu à l'autotests, a gestione hà stabilitu u compitu di valutà quale percentuale di u codice copremu. Cù una cobertura di più di 1%, a gestione seria felice. Avemu, i sviluppatori, aspittavamu un risultatu di circa 10%. Avemu installatu a cobertura di codice, a misurata, è ottene u 20%. Per celebrà, andemu per piglià u premiu, ma cumu andemu per piglià è induve andemu dopu hè una storia completamente diversa.

3. Autotests ponu verificà i servizii web esposti. Oracle ci permette di fà questu abbastanza bè, è ùn avemu più scontru una quantità di prublemi.
4. È, sicuru, u nostru sistema di teste automatizatu pò esse appiicatu à un altru prughjettu. A suluzione chì avemu ricevutu hè universale è esige solu l'usu di Oracle. Aghju intesu chì l'altri prughjetti di u Sportmaster anu interessatu à a prova automatica è forse andemu à elli.

scuperti

Riassumemu. In u prughjettu di u sistema di fidelizazione in Sportmaster, avemu riesciutu à implementà un sistema di teste automatizatu. Hè basatu annantu à a suluzione utPLSQL da Stephen Feuerstein. In u circondu utPLSQL ci hè codice autotest è moduli ausiliari scritti da sè stessu: modulu di lanciamentu, modulu di generazione di dati è altri. L'autotests sò lanciati ogni ghjornu è, più impurtante, travaglianu è sò utili. Semu cunfidenti chì avemu cuminciatu à liberà un software di qualità superiore. À u listessu tempu, a suluzione risultante hè universale è pò esse liberamente appiicata à qualsiasi prughjettu induve hè necessariu urganizà teste automatizati nantu à l'Oracle DBMS.

PS Stu articulu ùn hè micca assai specificu: ci hè assai testu è praticamenti micca esempi tecnichi. Se u tema hè in generale interessante, allora simu pronti à cuntinuà è vultà cun una continuazione, induve vi diceremu ciò chì hà cambiatu in l'ultimi sei mesi è furnisce esempi di codice.

Scrivite cumenti s'ellu ci sò punti chì deve esse enfatizzati in u futuru, o dumande chì necessitanu divulgazione.

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Scrivemu più nantu à questu?

• Iè, sicuru

• Innò grazie

12 utilizatori anu vutatu. 4 utilizatori si sò astenuti.

Source: www.habr.com