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

Parte prima - qui.

Immaginate la situazione. Avete il compito di sviluppare una nuova funzionalità. Avete a disposizione lavori precedenti dai vostri predecessori. Se consideriamo che non avete alcun obbligo morale, come vi comportereste?

Nella maggior parte dei casi, tutti i passati lavori vengono dimenticati e si riparte da zero. Nessuno ama spulciare il codice di qualcun altro, e se ci si trova davanti a del tempo, perché non dedicarsi alla creazione di un proprio sistema? Questo è un approccio tipico, e in gran parte corretto. Ma nel nostro progetto non abbiamo proceduto in questo modo. Abbiamo basato il futuro sistema di test automatici sulle esperienze di unit test su utPLSQL dei nostri predecessori, per poi lavorare in diverse direzioni parallele.

Ripristino dei vecchi unit test. Per ripristino si intende l'adattamento dei test allo stato attuale del sistema di loyalty e l'adattamento dei test agli standard utPLSQL.
Risolvere il problema della comprensione di quali metodi e processi siano coperti dai test automatici. Bisogna tenere queste informazioni a mente o trarre conclusioni direttamente dal codice dei test automatici. Pertanto, abbiamo deciso di formare un catalogo. Ad ogni test automatico abbiamo assegnato un codice mnemonico unico, abbiamo creato una descrizione e registrato le impostazioni (ad esempio, in quali condizioni deve essere eseguito o cosa deve succedere se il test fallisce). In sostanza, abbiamo riempito i metadati sui test automatici e inserito questi metadati nelle tabelle standard dello schema utPLSQL.
Definizione della strategia di ampliamento, ovvero selezione delle funzionalità da verificare con i test automatici. Abbiamo deciso di prestare attenzione a tre aspetti: nuove implementazioni del sistema, incidenti dalla produzione e processi chiave del sistema. In questo modo ci sviluppiamo parallelamente al rilascio, garantendo una qualità superiore e ampliando nel contempo l'area di regressione, assicurando la stabilità del sistema nei punti critici. La prima di queste strozzature è stata il processo di distribuzione di sconti e bonus nel pagamento.
Naturalmente, ci siamo messi al lavoro sulla creazione di nuovi test automatici. Uno dei primi compiti di rilascio è stata la valutazione delle prestazioni dei campioni predefiniti del sistema di fidelizzazione. Nel nostro progetto, abbiamo un blocco di query SQL fissate, che selezionano i clienti in base a determinati criteri. Ad esempio, ottenere un elenco di tutti i clienti la cui ultima acquisto è avvenuto in una città specifica, o un elenco di clienti la cui spesa media supera un valore definito. Scrivendo dei test automatici, abbiamo verificato i campioni predefiniti, registrato i parametri di riferimento delle prestazioni e, in aggiunta, abbiamo introdotto il testing di carico.
Lavorare con i test automatici deve essere comodo. Le due azioni più comuni sono: avvio dei test automatici e creazione di dati di test. Così, nel nostro sistema sono stati creati due moduli di supporto: un modulo di avvio e un modulo di generazione dati.
Il modulo di avvio è presentato come una singola procedura universale con un unico parametro di input testuale. Come parametro, si può passare il mnemonico del test automatico, il nome del pacchetto, il nome del test, le impostazioni del test automatico o una parola chiave riservata. La procedura seleziona e avvia tutti i test automatici che soddisfano le condizioni.
Il modulo di generazione dati è presentato come un pacchetto, in cui per ogni oggetto del sistema sottoposto a test (tabella nel DB), è stata creata una procedura speciale che inserisce dati. In questa procedura, i valori predefiniti sono riempiti al massimo, garantendo la creazione di oggetti in un attimo. E per comodità d'uso sono stati creati modelli di dati da generare. Ad esempio, creare un cliente di una certa età con un telefono di prova e un acquisto effettuato.
I test automatici devono avviarsi e funzionare in un tempo accettabile per il tuo sistema. Pertanto, è stato organizzato un avvio notturno giornaliero, i cui risultati generano un rapporto sulle prestazioni e viene inviato a tutto il team di sviluppo via e-mail aziendale. Dopo il ripristino dei vecchi test automatici e la creazione di nuovi, il tempo totale di esecuzione era di 30 minuti. Questa prestazione soddisfaceva tutti, poiché l'avvio avveniva al di fuori dell'orario lavorativo.
Ma abbiamo dovuto lavorare sull'ottimizzazione della velocità di funzionamento. L'aggiornamento del sistema di fidelizzazione in produzione avviene durante la notte. Durante uno dei rilasci, è stato necessario apportare modifiche urgenti nella notte. Una attesa di mezz'ora per i risultati dei test automatici alle tre di notte non ha reso felice il responsabile del rilascio (un caloroso saluto ad Aleksey Vasyukov!), e la mattina seguente sono state spese molte parole gentili verso il nostro sistema. Tuttavia, alla fine è stato stabilito un limite di 5 minuti per il lavoro.
Per aumentare le prestazioni, abbiamo utilizzato due metodi: i test automatici sono stati avviati in tre flussi paralleli, il che è stato molto conveniente grazie all'architettura del nostro sistema di fidelizzazione. Inoltre, abbiamo abbandonato l'approccio in cui il test automatico non crea dati di prova per sé ma cerca di trovare nel sistema qualcosa di appropriato. Dopo le modifiche, il tempo totale di esecuzione è stato ridotto a 3-4 minuti.
Il progetto con i test automatici deve poter essere distribuito su diversi stand. All'inizio del percorso ci sono stati tentativi di scrivere i propri script batch, ma è diventato chiaro che installazioni automatizzate scritte a mano sono un vero incubo, quindi ci siamo orientati verso soluzioni industriali. Poiché nel progetto ci sono molto codice (in primo luogo, memorizziamo il codice dei test automatici) e pochi dati (i dati principali sono i metadati sui test automatici), l'introduzione di Liquibase nel progetto è risultata molto semplice.
È una libreria indipendente dal database con codice sorgente aperto per monitorare, gestire e applicare modifiche agli schemi del database. Viene gestita tramite riga di comando o framework come Apache Maven. Il principio di funzionamento di Liquibase è piuttosto semplice. Abbiamo un progetto organizzato in un certo modo, composto da modifiche o script che devono essere applicati sul server di destinazione, e file di controllo che definiscono in quale sequenza e con quali parametri devono essere installate 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 al nostro sistema su qualsiasi ambiente. I test automatici vengono ora eseguiti sugli ambienti di test e di rilascio, così come sui container (ambienti personali degli sviluppatori).

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

Naturalmente, prima di tutto, siamo convinti di aver iniziato a sviluppare software di migliore qualità. I test automatici vengono eseguiti quotidianamente e ogni rilascio trova decine di errori. Inoltre, una parte di questi errori è solo indirettamente legata alla funzionalità che volevamo effettivamente cambiare. Ci sono grandi dubbi sul fatto che questi errori siano stati trovati tramite testing manuale.
Il team ha acquisito fiducia che una determinata funzionalità funzioni correttamente... Questo riguarda principalmente i nostri processi critici. Ad esempio, negli ultimi sei mesi non abbiamo avuto problemi con la distribuzione degli sconti e dei bonus sullo scontrino, nonostante le modifiche ad ogni rilascio, anche se nei periodi precedenti si verificavano periodicamente degli errori.
Siamo riusciti a ridurre il numero di iterazioni di test. Grazie al fatto che i test automatici vengono scritti su nuove funzionalità, gli analisti e testatori, a tempo pieno e congiuntamente, ricevono un codice di qualità superiore, poiché è già stato verificato.
Parte dei lavori di testing automatizzato viene utilizzata dagli sviluppatori. Ad esempio, i dati di test sui container vengono creati utilizzando un modulo di generazione di oggetti.
Non è di poco conto che abbiamo sviluppato un "accettazione" del sistema di testing automatizzato da parte degli sviluppatori. C'è consapevolezza che sia importante e utile. E dalla mia esperienza posso dire che non è affatto così. I test automatici devono essere scritti, devono essere mantenuti e sviluppati, analizzati i risultati, e spesso questi investimenti di tempo non valgono la pena. È molto più semplice andare in produzione e affrontare i problemi lì. Tuttavia, i nostri sviluppatori si mettono in fila e chiedono di coprire le loro funzionalità con test automatici.

E ora?

Parliamo dei piani di sviluppo del progetto di testing automatizzato.

Senza dubbio, finché il sistema di loyalty di Sportmaster è attivo e continua a svilupparsi, possiamo anche sviluppare praticamente all'infinito i test automatici. Pertanto, la principale direzione di sviluppo è l'espansione dell'area di copertura.

Con l'aumento del numero di test automatici, aumenterà inesorabilmente anche il tempo totale di esecuzione, e dovremo nuovamente affrontare la questione delle prestazioni. Probabilmente, la soluzione consisterà nell'aumentare il numero di flussi paralleli.

Ma queste sono strade di sviluppo ovvie. Parlare di qualcosa di più non banale, evidenziamo quanto segue:

Attualmente, la gestione dei test automatici viene effettuata a livello di database, cioè sono necessarie conoscenze di PL/SQL per lavorare con successo. Quando necessario, la gestione del sistema (ad esempio, avviare esecuzioni o creare metadati) può essere realizzata tramite un'interfaccia di amministrazione, utilizzando Jenkins o qualcosa di simile.
Tutti amano indicatori quantitativi e qualitativi. Per i test automatici, un indicatore universale è il Codice di Copertura o la 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 la possibilità di calcolare questa metrica e propone 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 (un progetto diverso da Sportmaster) è successo proprio così. Un anno dopo l'inizio del lavoro sui test automatici, la direzione ha richiesto di valutare quale percentuale di codice fossimo in grado di coprire. Con una copertura superiore all'1%, la direzione sarebbe stata felice. Noi sviluppatori ci aspettavamo un risultato attorno al 10%. Abbiamo implementato il codice di copertura, misurato, e abbiamo ottenuto il 20%. Con grande entusiasmo ci siamo recati a richiedere un premio, ma come ci siamo comportati in merito e dove siamo andati dopo, è tutta un'altra storia.
I test automatici possono verificare i servizi web esposti. Oracle lo consente ampiamente, e noi non ci imbatteremo più in tutta una serie di problemi.
E, naturalmente, il nostro sistema di test automatizzati può essere applicato a un altro progetto. La soluzione che abbiamo ottenuto è universale e richiede solo l'uso di Oracle. Ho sentito che ci sono interessi in progetti diversi di Sportmaster per il testing automatico e, forse, ci dirigeremo verso di loro.

Conclusioni

Ricapitoliamo. Nel progetto del sistema di fidelizzazione di Sportmaster, siamo riusciti a implementare un sistema di test automatizzati. La base è una soluzione utPLSQL di Steven Feuerstein. Attorno a utPLSQL si trova il codice dei test automatici e moduli ausiliari scritti da noi: modulo di avvio, modulo di generazione dei dati e altri. I test automatici vengono eseguiti quotidianamente e, cosa più importante, funzionano e apportano benefici. Siamo convinti di aver iniziato a rilasciare software di qualità superiore. Inoltre, la soluzione ottenuta è universale e può essere liberamente applicata a qualsiasi progetto che richieda l'organizzazione del testing automatizzato su DBMS Oracle.

P.S. Questo articolo è risultato non molto specifico: ci sono molte parole e quasi nessun esempio tecnico. Se in generale l'argomento è interessante, siamo pronti a continuarlo e tornare con un seguito, in cui parleremo di cosa è cambiato negli ultimi sei mesi e forniremo esempi di codice.

Scrivete nei commenti se ci sono aspetti su cui vale la pena concentrare l'attenzione in futuro, o domande che richiedono chiarimenti.

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