Unit test in DBMS – come lo facciamo in Sportmaster, parte prima

Ciao, Habr!

Mi chiamo Maxim Ponomarenko e sono un sviluppatore di Sportmaster. Ho un'esperienza di 10 anni nel settore IT. Ho iniziato la mia carriera nel campo del testing manuale, per poi passare allo sviluppo di database. Negli ultimi 4 anni, accumulando conoscenze acquisite nel testing e nello sviluppo, mi occupo di automazione dei test a livello di DBMS.

Faccio parte del team di Sportmaster da poco più di un anno e in uno dei grandi progetti mi occupo dello sviluppo di test automatizzati. In aprile, insieme ai ragazzi di Sportmaster Lab, abbiamo partecipato a una conferenza a Krasnodar, il mio intervento si intitolava «Unit test nel DBMS», e ora voglio condividerlo con voi. Ci sarà molto testo, quindi ho deciso di suddividere l'intervento in due post. Nel primo parleremo di test automatici e testing in generale, mentre nel secondo mi soffermerò di più sul nostro sistema di unit testing e sui risultati che ha portato.

Iniziamo con un po' di teoria noiosa. Che cos'è il testing automatico? È un tipo di test condotto tramite strumenti software, e nel moderno IT viene sempre più utilizzato durante lo sviluppo software. Questo accade perché le aziende crescono, le loro sistemi informatici si espandono e, di conseguenza, aumenta anche la quantità di funzionalità da testare. Effettuare test manuali sta diventando sempre più costoso.

Ho lavorato in una grande azienda i cui rilasci avvengono ogni due mesi. Durante questo tempo, un mese intero veniva speso affinché una decina di tester controllasse manualmente le funzionalità. Grazie all'implementazione dell'automazione, un piccolo team di sviluppatori è riuscito, in un anno e mezzo, a ridurre il tempo di testing a 2 settimane. Non solo abbiamo aumentato la velocità del testing, ma ne abbiamo anche migliorato la qualità. I test automatici vengono eseguiti regolarmente e coprono sempre l'intero corso di controlli predefiniti, escludendo così il fattore umano.

Nel mondo IT moderno, è comune che gli sviluppatori siano chiamati non solo a scrivere il codice del prodotto, ma anche a realizzare test unitari che lo verifichino.

Ma cosa fare se il tuo sistema si basa principalmente sulla logica server-side? Non esiste una soluzione universale o best practices consolidate sul mercato. Di solito, le aziende affrontano questo problema creando un proprio sistema di testing su misura. In questo contesto, è stato sviluppato un sistema di test automatizzato nel nostro progetto, di cui parlerò nella mia presentazione.

Testiamo la fedeltà

Per iniziare, parliamo del progetto in cui abbiamo implementato il sistema di test automatizzati. Il nostro progetto è il sistema di fidelizzazione di Sportmaster (tra l'altro, abbiamo già scritto di questo nel questo post).

Se la tua azienda è abbastanza grande, il tuo sistema di fidelizzazione avrà tre caratteristiche standard:

• Il tuo sistema sarà ad alta capacità di carico
• Il tuo sistema conterrà processi computazionali complessi
• Il tuo sistema sarà attivamente aggiornato.

Andiamo con ordine... In totale, considerando tutti i marchi di Sportmaster, abbiamo oltre 1000 negozi in Russia, Ucraina, Cina, Kazakistan e Bielorussia. In questi negozi si effettuano circa 300.000 acquisti ogni giorno. Questo significa che ogni secondo nel nostro sistema arrivano 3-4 scontrini. Naturalmente, il nostro sistema di fidelizzazione è molto caricato. E poiché viene utilizzato attivamente, dobbiamo fornire i più alti standard di qualità, poiché qualsiasi errore nel software comporta grandi perdite economiche, di reputazione e altro.

Contemporaneamente, in Sportmaster è attivo oltre un centinaio di diverse promozioni. Le promozioni sono variegate: ci sono quelle sui prodotti, quelle legate ai giorni della settimana, promozioni specifiche per negozi, sconti sull'importo dello scontrino e promozioni sul numero di prodotti. Insomma, non è da poco. I clienti hanno dei bonus e codici promozionali che possono utilizzare durante gli acquisti. Tutto ciò porta al fatto che il calcolo di qualsiasi ordine è un compito piuttosto complesso.

L'algoritmo che gestisce il processo di ordinazione è davvero complesso e difficile da comprendere. Qualsiasi modifica apportata a questo algoritmo è un'operazione rischiosa. Anche le modifiche che sembrano minime possono generare effetti decisamente imprevedibili. E proprio per queste ragioni, i processi computazionali complessi, specialmente quelli che implementano funzionalità critiche, sono i migliori candidati per essere automatizzati. Controllare manualmente decine di casi simili richiede troppo tempo. E dato che il punto di accesso al processo rimane invariato, descrivendolo una sola volta, è possibile generare rapidamente test automatici e avere la certezza che la funzionalità funzioni correttamente.

Poiché il nostro sistema è utilizzato attivamente, le aziende si aspettano da voi qualcosa di nuovo, vogliono essere al passo con i tempi e orientare il servizio verso il cliente. Nel nostro sistema di fedeltà, le versioni vengono rilasciate ogni due mesi. Questo significa che ogni due mesi dobbiamo eseguire un regressivo completo dell'intero sistema. Naturalmente, come in qualsiasi moderno IT, lo sviluppo non passa direttamente dagli sviluppatori alla produzione. Inizia nel contesto dello sviluppatore, poi passa gradualmente attraverso gli ambienti di test, rilascio, accettazione e solo allora arriva in produzione. Almeno negli ambienti di test e di rilascio dobbiamo eseguire un regressivo completo dell'intero sistema.

Le proprietà descritte sono standard per quasi tutti i sistemi di fedeltà. Parliamo ora delle particolarità del nostro progetto.

La logica tecnologica del nostro sistema di fidelizzazione è per il 90% server-based e implementata su Oracle. Esiste un client basato su Delphi che funge da ARM-administratore. Sono stati implementati web service per le applicazioni esterne (come il sito web). È quindi logico che, se decidiamo di attivare un sistema di testing automatizzato, lo faremo su Oracle.

Il sistema di fidelizzazione di Sportmaster esiste da oltre 7 anni ed è stato creato da sviluppatori singoli… Il numero medio di sviluppatori nel nostro progetto durante questi 7 anni è stato di 3-4 persone. Ma nell'ultimo anno la nostra squadra è cresciuta notevolmente, e ora sul progetto lavorano 10 persone. Questo significa che nel progetto arrivano persone che non sono familiari con le attività standard, i processi e l'architettura. E c'è un rischio maggiore che potremmo trascurare errori.

Il progetto è caratterizzato dall'assenza di tester dedicati come unità fisse. Certamente ci sono attività di testing, ma sono svolte dagli analisti, oltre ai loro altri principali compiti: comunicazione con i business client, utenti, elaborazione dei requisiti del sistema, ecc. Nonostante il testing venga eseguito con grande qualità (è opportuno sottolinearlo, poiché potrebbe capitare che uno degli analisti legga questo report), l'efficacia della specializzazione e la concentrazione su un'unica area non può essere ignorata.

Tenendo conto di quanto sopra, per migliorare la qualità del prodotto offerto e ridurre i tempi di sviluppo, l'idea di automatizzare i test nel progetto appare piuttosto logica. In diverse fasi dell'esistenza del sistema di fidelizzazione, singoli sviluppatori hanno fatto sforzi per coprire il proprio codice con test unitari. Questo è stato in generale un processo abbastanza frammentato, dove ognuno utilizzava la propria architettura e i propri metodi. I risultati comuni per i test unitari erano: i test venivano sviluppati, utilizzati per un certo periodo, archiviati in un repository di versioni, ma a un certo punto smettevano di essere eseguiti e venivano dimenticati. Questo accadeva principalmente perché i test erano più legati a un singolo esecutore piuttosto che al progetto.

Aggiunge un supporto utPLSQL

Sai qualcosa su Steven Feuerstein?

Questo è un tizio intelligente che ha dedicato gran parte della sua carriera a lavorare con Oracle e PL/SQL, scrivendo un numero considerevole di trattati su questo argomento. Uno dei suoi libri più noti si intitola "Oracle PL/SQL. Per professionisti". A Stephen si deve lo sviluppo della soluzione utPLSQL, ovvero il framework di test unitari per Oracle PL/SQL. La soluzione utPLSQL è stata creata nel 2016, ma è continua ad essere attivamente sviluppata e vengono rilasciate nuove versioni. Al momento della presentazione, l'ultima versione è datata 24 marzo 2019.
Che cos'è? È un progetto open source separato. Occupa un paio di megabyte, compresi esempi e documentazione. Rappresenta fisicamente uno schema separato nel database ORACLE con un insieme di pacchetti e tabelle per l'organizzazione dei test unitari. L'installazione richiede solo pochi secondi. Una caratteristica distintiva di utPLSQL è la sua semplicità d'uso.
A livello globale, utPLSQL è un meccanismo per l'esecuzione di unit test, dove per unit test si intendono normali procedure di pacchetti Oracle, la cui organizzazione segue alcune regole. Oltre all'esecuzione, utPLSQL memorizza un log di tutti i tuoi esecuzioni di test e dispone di un sistema di reporting interno.

Vediamo un esempio di come appare il codice di un unit test implementato secondo questa metodologia.

Quindi, sullo schermo è mostrato il codice di una tipica specifica di pacchetto con unit test. Quali sono i requisiti obbligatori? Il pacchetto deve avere il prefisso «utp_». Lo stesso prefisso deve avere ogni procedura con test. Nel pacchetto devono necessariamente essere presenti due procedure standard: «utp_setup» e «utp_teardown». La prima procedura viene chiamata all'inizio di ogni unit test, la seconda dopo l'esecuzione.

«utp_setup», di solito, prepara il nostro sistema per l'esecuzione dell'unit test, ad esempio, creando dati di test. «utp_teardown», al contrario, riporta tutto alle impostazioni iniziali e cancella i risultati dell'esecuzione.

Ecco un esempio del più semplice test unitario, che verifica la normalizzazione del numero di telefono fornito dal cliente al formato standard del nostro sistema di fidelizzazione. Non ci sono standard obbligatori su come scrivere le procedure con i test unitari. Di solito, viene chiamato un metodo di un sistema in fase di test, e il risultato restituito da questo metodo viene confrontato con quello di riferimento. È importante che il confronto tra il risultato di riferimento e quello ottenuto avvenga tramite metodi standard utPLSQL.

Nel test unitario possono esserci quantità variabili di verifiche. Come si può vedere dall'esempio, facciamo quattro chiamate consecutive al metodo in fase di test per la normalizzazione del numero di telefono e dopo ogni chiamata valutiamo il risultato. Durante lo sviluppo del test unitario è importante tenere presente che ci sono controlli che non influenzano in alcun modo il sistema, mentre dopo alcuni è necessario riportare il sistema allo stato originale.
Ad esempio, nel test unitario presentato formattiamo semplicemente il numero di telefono in ingresso, il che non influisce in alcun modo sul sistema di fidelizzazione.

Se scriviamo test unitari per il metodo di creazione di un nuovo cliente, dopo ogni verifica verrà creato un nuovo cliente nel sistema, il che potrebbe influenzare le esecuzioni successive del test.

Ecco come vengono eseguiti i test unitari. Sono ammesse due modalità di esecuzione: l'esecuzione di tutti i test unitari da un pacchetto specifico o l'esecuzione di un test unitario specifico all'interno di un pacchetto.

Ecco un esempio di sistema di reportistica interna. Sulla base dei risultati dei test unitari, utPLSQL genera un piccolo rapporto. In esso vediamo il risultato di ogni specifica verifica e il risultato complessivo dell'esecuzione del test unitario.

6 regole per i test automatici

Prima di iniziare a creare un nuovo sistema di test automatizzati per il sistema di fidelizzazione, insieme alla direzione abbiamo definito i principi a cui dovranno attenersi i nostri futuri test automatici.

1. I test automatizzati devono essere efficaci e portare dei benefici. Abbiamo degli sviluppatori straordinari di cui vale la pena parlare, perché qualcuno di loro sicuramente vedrà questa presentazione, e scrivono codice eccellente. Ma anche il loro codice straordinario non è perfetto e ha, ha e avrà degli errori. I test automatizzati devono individuare questi errori. Se non lo fanno, allora stiamo scrivendo test automatizzati scadenti oppure siamo arrivati in un'area morta che in pratica non vengono migliorati. In entrambi i casi, stiamo facendo qualcosa di sbagliato e il nostro approccio è semplicemente privo di senso.
2. I test automatizzati devono essere utilizzati. È insensato spendere un sacco di tempo e risorse per scrivere un prodotto software, caricarne il repository e dimenticarsene. I test devono essere eseguiti, e il più regolarmente possibile.
3. I test automatizzati devono funzionare in modo stabile. Indipendentemente dall'ora del giorno, dallo stand di esecuzione e da altre impostazioni di sistema, le esecuzioni dei test devono portare sempre allo stesso risultato. Di solito, questo è garantito dal fatto che i test automatizzati lavorano con dati di test specifici e impostazioni di sistema fisse.
4. I test automatizzati devono operare a una velocità accettabile per il tuo progetto. Questo tempo è definito individualmente per ogni sistema. Alcuni possono permettersi di lavorare tutto il giorno, mentre per altri è cruciale completare il lavoro in pochi secondi. Più tardi ti racconterò quali standard di velocità abbiamo raggiunto nel nostro progetto.
5. Lo sviluppo degli autotest deve essere flessibile. Non è auspicabile rinunciare alla verifica di nessuna funzionalità solo perché non l'abbiamo mai fatto prima o per altri motivi. utPLSQL non impone alcun vincolo allo sviluppo, e Oracle, in linea di principio, consente di realizzare le più svariate cose. La maggior parte delle attività ha una soluzione, la questione è solo di tempo e impegno spesi.
6. Distribuibilità. Abbiamo diversi ambienti dove è necessario eseguire i test. In ciascuno di questi ambienti, il dump dei dati può essere aggiornato in qualsiasi momento. È necessario gestire il progetto con autotest in modo da poter effettuare una sua installazione totale o parziale senza inconvenienti.

E in un secondo post tra qualche giorno ti racconterò cosa abbiamo fatto e quali risultati abbiamo raggiunto.

Fonte: habr.com