🥇Unit test nei DBMS — come lo facciamo in Sportmaster, parte seconda

La prima parte è — qui.

Immagina la situazione. Hai il compito di sviluppare una nuova funzionalità. Hai a disposizione il lavoro dei tuoi predecessori. Se assumiamo che tu non abbia alcun obbligo morale, come ti comporteresti?

Nella maggior parte dei casi, tutto il lavoro precedente viene dimenticato e si inizia da capo. A nessuno piace lavorare su codice di qualcun altro e, se c'è tempo, perché non dedicarsi a creare un sistema tutto tuo? Questo è un approccio tipico e, in gran parte, corretto. Ma nel nostro progetto non abbiamo agito in questo modo. Abbiamo basato il nostro futuro sistema di testing automatico sui lavori riguardanti i test unitari su utPLSQL dei predecessori, e poi abbiamo iniziato a lavorare in diverse direzioni parallele.

Ripristino dei vecchi test unitari. Per ripristino si intende l'adattamento dei test allo stato attuale del sistema di fidelizzazione e l'adattamento dei test agli standard di utPLSQL.
Risoluzione del problema di comprensione su quali metodi e processi siano coperti dai nostri test automatici. È necessario tenere a mente queste informazioni o trarre conclusioni direttamente dal codice dei test automatici. Pertanto, abbiamo deciso di creare un catalogo. A ciascun test automatico abbiamo assegnato un codice mnemonico unico, redatto una descrizione e registrato le impostazioni (come, ad esempio, in quali condizioni deve essere eseguito o cosa deve succedere se il test fallisce). In sostanza, abbiamo compilato i metadati sui test automatici e inserito questi metadati nelle tabelle standard dello schema utPLSQL.
Definizione della strategia di estensione, cioè la scelta delle funzionalità da controllare con i test automatici. Abbiamo deciso di concentrarci su tre aspetti: nuove modifiche al sistema, incidenti in produzione e processi chiave del sistema. In questo modo, ci sviluppiamo parallelamente al rilascio, garantendo una qualità superiore e, nel contempo, ampliando l'ambito del testing di regressione e assicurando l'affidabilità del sistema nei punti critici. Il primo di questi colli di bottiglia è stato il processo di distribuzione degli sconti e dei bonus sullo scontrino.
Naturalmente, ci siamo dedicati allo sviluppo di nuovi test automatici. Una delle prime attività di rilascio è stata la valutazione delle performance dei campioni predefiniti del sistema di fidelizzazione. Nel nostro progetto è presente un blocco di query SQL fisse che selezionano i clienti in base a determinate condizioni. Ad esempio, ottenere un elenco di tutti i clienti la cui ultima acquisto è avvenuto in una specifica città, o un elenco di clienti la cui media di spesa supera un valore predeterminato. Scrivendo test automatizzati, abbiamo verificato i campioni predefiniti, registrato i parametri di performance di riferimento e inoltre abbiamo introdotto il test di carico.
Lavorare con i test automatizzati deve essere comodo. Le due azioni più comuni sono: l'esecuzione dei test automatizzati e la creazione di dati di test. Così nel nostro sistema sono stati introdotti due moduli ausiliari: il modulo di esecuzione e il modulo di generazione dati.
Il modulo di avvio è presentato come una singola procedura universale con un parametro di testo in ingresso. Come parametro, è possibile passare il mnemonic code del test automatico, il nome del pacchetto, il nome del test, la configurazione del test automatico o una parola chiave riservata. La procedura seleziona e avvia tutti i test automatici che soddisfano i criteri.
Il modulo di generazione dei dati è presentato come un pacchetto, in cui per ogni oggetto del sistema in fase di test (tabella nel database), è stata creata una procedura speciale che inserisce i dati al suo interno. In questa procedura, i valori predefiniti sono stati massimamente riempiti, il che garantisce la creazione di oggetti con un semplice clic. Inoltre, sono stati creati modelli per i dati generati, come ad esempio la creazione di un cliente di una certa età con un numero di telefono di prova e un acquisto effettuato.
I test automatici devono essere avviati e funzionare entro un tempo accettabile per il vostro sistema. Per questo motivo è stato organizzato un avvio notturno quotidiano, i cui risultati vengono raccolti in un rapporto e inviati a tutto il team di sviluppo via email aziendale. Dopo il ripristino dei vecchi test automatici e la creazione di nuovi, il tempo totale di esecuzione è stato di 30 minuti. Tale produttività ha soddisfatto tutti, poiché l'esecuzione avveniva al di fuori dell'orario lavorativo.
Tuttavia, è stato necessario lavorare per ottimizzare la velocità operativa. L'aggiornamento del sistema di fidelizzazione in produzione avviene di notte. Durante uno dei rilasci, sono stati effettuati cambiamenti urgenti durante la notte. Mezz'ora di attesa per i risultati dei test automatici alle tre del mattino non ha reso felice il responsabile del rilascio (un affettuoso saluto ad Alexey Vasyukov!), e la mattina seguente sono stati spesi molti complimenti verso il nostro sistema. Tuttavia, alla fine è stato stabilito un standard di 5 minuti per il lavoro.
Per migliorare le prestazioni, abbiamo utilizzato due metodi: i test automatici vengono eseguiti su tre flussi paralleli, grazie all'architettura del nostro sistema di fidelizzazione. Abbiamo anche abbandonato l'approccio in cui i test automatici non generano i dati di test autonomamente, ma cercano qualcosa di pertinente nel sistema. Dopo le modifiche, il tempo totale di esecuzione è stato ridotto a 3-4 minuti.
È necessario poter distribuire il progetto con i test automatici su diversi ambienti. All'inizio abbiamo provato a scrivere i nostri script di installazione, ma ci siamo resi conto che l'installazione automatizzata scritta in casa era un completo disastro; quindi ci siamo orientati verso soluzioni industriali. Poiché nel progetto ci sono molte righe di codice (soprattutto memorizziamo il codice dei test automatici) e pochi dati (i dati principali sono metadati sui test automatici), è stato abbastanza semplice implementare Liquibase nel progetto.
Liquibase è una libreria open source indipendente dal database, utilizzata per monitorare, gestire e applicare le modifiche della schema del database. Può essere gestita tramite linea di comando o framework come Apache Maven. Il funzionamento di Liquibase è abbastanza semplice. Abbiamo un progetto organizzato in un certo modo, composto da modifiche o script da applicare al server target, e file di controllo che definiscono in quale ordine e con quali parametri applicare queste modifiche.
A livello di DBMS, viene creata una tabella speciale in cui Liquibase memorizza il log delle applicazioni. Ogni modifica ha un hash calcolato che viene confrontato ogni volta tra il progetto e lo stato nel database. Grazie a Liquibase, possiamo facilmente applicare le modifiche del nostro sistema su qualsiasi ambiente. I test automatici vengono ora eseguiti sugli ambienti di test e di produzione, così come su container (ambienti personali degli sviluppatori).

Quindi, parliamo dei risultati dell'applicazione del nostro sistema di unit test.

Certamente, prima di tutto, siamo convinti che abbiamo iniziato a sviluppare software di qualità superiore. I test automatici vengono eseguiti quotidianamente e ogni rilascio trova decine di errori. Inoltre, alcuni di questi errori sono solo indirettamente correlati alle funzionalità che volevamo realmente modificare. Ci sono grandi dubbi sul fatto che questi errori siano stati trovati tramite test manuali.
Il team ha acquisito fiducia che una specifica funzionalità funzioni correttamente… Questo è particolarmente vero per i nostri processi critici. Ad esempio, negli ultimi sei mesi non abbiamo avuto problemi nella distribuzione di sconti e bonus in cassa, nonostante le modifiche rilasciate ogni volta, mentre in periodi precedenti si sono verificati errori con certa periodicità.
Siamo riusciti a ridurre il numero di iterazioni di test. Grazie al fatto che i test automatici sono scritti per le nuove funzionalità, gli analisti e, allo stesso tempo, i tester ricevono codice di qualità superiore, poiché è già stato verificato.
Alcune delle tecnologie di testing automatizzato vengono utilizzate dagli sviluppatori. Ad esempio, i dati di test sui contenitori vengono creati utilizzando un modulo di generazione degli oggetti.
È importante notare che abbiamo raggiunto un'accettazione del sistema di test automatici da parte degli sviluppatori. C'è consapevolezza che sia fondamentale e utile. Tuttavia, dalla mia esperienza, posso dire che non è affatto così. I test automatici devono essere scritti, mantenuti e sviluppati, con analisi dei risultati, e spesso questi sforzi temporali non valgono la pena. È molto più semplice andare in produzione e affrontare i problemi lì. I nostri sviluppatori, infatti, fanno la fila e chiedono di coprire le loro funzionalità con i test automatici.

Cosa succede dopo

Parliamo dei piani di sviluppo del progetto di test automatico.

Senza dubbio, finché il sistema di fedeltà di Sportmaster è vivo e continua a svilupparsi, possiamo espandere quasi all'infinito i test automatici. Pertanto, la principale direzione di sviluppo è l'espansione della copertura.

Con l'aumento del numero di test automatici, il tempo complessivo di esecuzione crescerà inevitabilmente, e dovremo tornare a considerare la questione delle prestazioni. Probabilmente, la soluzione consisterà nell'aumentare il numero di flussi paralleli.

Tuttavia, questi sono percorsi di sviluppo evidenti. Se parliamo di qualcosa di più non triviale, evidenziamo quanto segue:

Attualmente la gestione dei test automatici avviene a livello di DBMS, cioè è necessaria la conoscenza di PL/SQL per lavorare con successo. Se necessario, è possibile spostare la gestione del sistema (ad esempio, l'esecuzione di avviamenti o la creazione di metadati) in un'interfaccia di amministrazione, utilizzando Jenkins o qualcosa di simile.
Tutti amano gli indicatori quantitativi e qualitativi. Per i test automatici, un indicatore universale è la Code Coverage o metrica di copertura del codice. Con questo indicatore possiamo determinare quale percentuale del codice del nostro sistema in fase di test è coperta dai test automatici. A partire dalla versione 12.2, Oracle offre funzionalità per il calcolo di questa metrica e suggerisce di utilizzare il pacchetto standard DBMS_PLSQL_CODE_COVERAGE.
Il nostro sistema di test automatici ha poco più di un anno e forse ora è il momento giusto per valutare la copertura. Nel mio progetto precedente (che non era di Sportmaster) è andata proprio così. Dopo un anno di lavoro sui test automatici, la direzione ha chiesto di valutare quale percentuale di codice stessimo coprendo. Con una copertura superiore all'1%, la direzione sarebbe stata felice. Noi sviluppatori ci aspettavamo un risultato attorno al 10%. Abbiamo attivato la misurazione della code coverage, fatto i calcoli e ottenuto il 20%. Con entusiasmo ci siamo diretti a richiedere un premio, ma come è andata e dove ci siamo diretti dopo è un'altra storia del tutto diversa.
I test automatici possono verificare i servizi web esposti. Oracle permette benissimo di farlo, e noi non ci imbatteremo più in una serie di problemi.
E naturalmente, il nostro sistema di testing automatico può essere applicato ad un altro progetto. La soluzione che abbiamo ottenuto è universale e richiede semplicemente l'uso di Oracle. Ho sentito che ci sono interessi verso il testing automatico in altri progetti di Sportmaster e, probabilmente, ci dirigeremo verso di loro.

Conclusioni

Riepiloghiamo. Nel progetto del sistema di fedeltà di Sportmaster, siamo riusciti a implementare un sistema di test automatizzati. La base di questo sistema è la soluzione utPLSQL di Steven Feuerstein. Intorno a utPLSQL si trova il codice dei test automatici e moduli ausiliari scritti in proprio: modulo di avvio, modulo di generazione dei dati e altri. I test automatici vengono eseguiti quotidianamente e, cosa più importante, funzionano e portano beneficio. Siamo convinti di aver iniziato a rilasciare software di qualità superiore. Inoltre, la soluzione ottenuta è universale e può essere facilmente applicata a qualsiasi progetto che necessita di organizzare test automatizzati su database Oracle.

P.S. Questo articolo non è molto specifico: contiene molto testo e praticamente nessun esempio tecnico. Se il tema generale è interessante, siamo pronti a continuarne la trattazione e tornare con un seguito, dove racconteremo cosa è cambiato negli ultimi sei mesi e porteremo esempi di codice.

Scrivete nei commenti se ci sono aspetti su cui dovremmo concentrarci in futuro o domande che richiedono approfondimenti.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.