{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Unit test nei DB \u2014 come lo facciamo da Sportmaster, parte seconda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La prima parte \u00e8 \u2014 qui<\/a><\/noindex>.<\/i><\/p>\n

\"Unit<\/a><\/noindex><\/p>\n

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

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'\u00e8 tempo, perch\u00e9 non dedicarsi a creare un sistema tutto tuo? Questo \u00e8 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.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Ripristino dei vecchi test unitari.<\/b> Per ripristino si intende l'adattamento dei test allo stato attuale del sistema di fidelizzazione e l'adattamento dei test agli standard di utPLSQL. <\/li>\n
  2. Risoluzione del problema di comprensione su quali metodi e processi siano coperti dai nostri test automatici. <\/b>\u00c8 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.<\/li>\n
  3. Definizione della strategia di estensione, cio\u00e8 la scelta delle funzionalit\u00e0 da controllare con i test automatici.<\/b> 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\u00e0 superiore e, nel contempo, ampliando l'ambito del testing di regressione e assicurando l'affidabilit\u00e0 del sistema nei punti critici. Il primo di questi colli di bottiglia \u00e8 stato il processo di distribuzione degli sconti e dei bonus sullo scontrino.<\/li>\n
  4. Naturalmente, ci siamo dedicati allo sviluppo di nuovi test automatici. <\/b>Una delle prime attivit\u00e0 di rilascio \u00e8 stata la valutazione delle performance dei campioni predefiniti del sistema di fidelizzazione. Nel nostro progetto \u00e8 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 \u00e8 avvenuto in una specifica citt\u00e0, 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.<\/li>\n
  5. Lavorare con i test automatizzati deve essere comodo<\/b>. Le due azioni pi\u00f9 comuni sono: l'esecuzione dei test automatizzati e la creazione di dati di test. Cos\u00ec nel nostro sistema sono stati introdotti due moduli ausiliari: il modulo di esecuzione e il modulo di generazione dati.\n

    Il modulo di avvio \u00e8 presentato come una singola procedura universale con un parametro di testo in ingresso. Come parametro, \u00e8 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.<\/p>\n

    Il modulo di generazione dei dati \u00e8 presentato come un pacchetto, in cui per ogni oggetto del sistema in fase di test (tabella nel database), \u00e8 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\u00e0 con un numero di telefono di prova e un acquisto effettuato.<\/li>\n

  6. I test automatici devono essere avviati e funzionare entro un tempo accettabile per il vostro sistema. <\/b>Per questo motivo \u00e8 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 \u00e8 stato di 30 minuti. Tale produttivit\u00e0 ha soddisfatto tutti, poich\u00e9 l'esecuzione avveniva al di fuori dell'orario lavorativo.\n

    Tuttavia, \u00e8 stato necessario lavorare per ottimizzare la velocit\u00e0 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 \u00e8 stato stabilito un standard di 5 minuti per il lavoro.<\/p>\n

    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 \u00e8 stato ridotto a 3-4 minuti.<\/li>\n

  7. \u00c8 necessario poter distribuire il progetto con i test automatici su diversi ambienti.<\/b> 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\u00e9 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), \u00e8 stato abbastanza semplice implementare Liquibase nel progetto.\n

    Liquibase \u00e8 una libreria open source indipendente dal database, utilizzata per monitorare, gestire e applicare le modifiche della schema del database. Pu\u00f2 essere gestita tramite linea di comando o framework come Apache Maven. Il funzionamento di Liquibase \u00e8 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. <\/p>\n

    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\u00ec come su container (ambienti personali degli sviluppatori).<\/li>\n<\/ol>\n

    \"Unit
    \n
    \nQuindi, parliamo dei risultati dell'applicazione del nostro sistema di unit test. <\/p>\n

      \n
    1. Certamente, prima di tutto, siamo convinti che abbiamo iniziato a sviluppare software di qualit\u00e0 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\u00e0 che volevamo realmente modificare. Ci sono grandi dubbi sul fatto che questi errori siano stati trovati tramite test manuali. <\/li>\n
    2. Il team ha acquisito fiducia che una specifica funzionalit\u00e0 funzioni correttamente\u2026 Questo \u00e8 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\u00e0.<\/li>\n
    3. Siamo riusciti a ridurre il numero di iterazioni di test. Grazie al fatto che i test automatici sono scritti per le nuove funzionalit\u00e0, gli analisti e, allo stesso tempo, i tester ricevono codice di qualit\u00e0 superiore, poich\u00e9 \u00e8 gi\u00e0 stato verificato.<\/li>\n
    4. 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.<\/li>\n
    5. \u00c8 importante notare che abbiamo raggiunto un'accettazione del sistema di test automatici da parte degli sviluppatori. C'\u00e8 consapevolezza che sia fondamentale e utile. Tuttavia, dalla mia esperienza, posso dire che non \u00e8 affatto cos\u00ec. I test automatici devono essere scritti, mantenuti e sviluppati, con analisi dei risultati, e spesso questi sforzi temporali non valgono la pena. \u00c8 molto pi\u00f9 semplice andare in produzione e affrontare i problemi l\u00ec. I nostri sviluppatori, infatti, fanno la fila e chiedono di coprire le loro funzionalit\u00e0 con i test automatici.<\/li>\n<\/ol>\n

      Cosa succede dopo<\/h2>\n

      \n\"Unit
      \n
      \nParliamo dei piani di sviluppo del progetto di test automatico.<\/p>\n

      Senza dubbio, finch\u00e9 il sistema di fedelt\u00e0 di Sportmaster \u00e8 vivo e continua a svilupparsi, possiamo espandere quasi all'infinito i test automatici. Pertanto, la principale direzione di sviluppo \u00e8 l'espansione della copertura.<\/p>\n

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

      Tuttavia, questi sono percorsi di sviluppo evidenti. Se parliamo di qualcosa di pi\u00f9 non triviale, evidenziamo quanto segue:<\/p>\n

        \n
      1. Attualmente la gestione dei test automatici avviene a livello di DBMS, cio\u00e8 \u00e8 necessaria la conoscenza di PL\/SQL per lavorare con successo. Se necessario, \u00e8 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.<\/li>\n
      2. Tutti amano gli indicatori quantitativi e qualitativi. Per i test automatici, un indicatore universale \u00e8 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 \u00e8 coperta dai test automatici. A partire dalla versione 12.2, Oracle offre funzionalit\u00e0 per il calcolo di questa metrica e suggerisce di utilizzare il pacchetto standard DBMS_PLSQL_CODE_COVERAGE.\n

        Il nostro sistema di test automatici ha poco pi\u00f9 di un anno e forse ora \u00e8 il momento giusto per valutare la copertura. Nel mio progetto precedente (che non era di Sportmaster) \u00e8 andata proprio cos\u00ec. 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 \u00e8 andata e dove ci siamo diretti dopo \u00e8 un'altra storia del tutto diversa.<\/li>\n

      3. I test automatici possono verificare i servizi web esposti. Oracle permette benissimo di farlo, e noi non ci imbatteremo pi\u00f9 in una serie di problemi. <\/li>\n
      4. E naturalmente, il nostro sistema di testing automatico pu\u00f2 essere applicato ad un altro progetto. La soluzione che abbiamo ottenuto \u00e8 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.<\/li>\n<\/ol>\n

        <\/p>\n

        Conclusioni<\/h2>\n

        \nRiepiloghiamo. Nel progetto del sistema di fedelt\u00e0 di Sportmaster, siamo riusciti a implementare un sistema di test automatizzati. La base di questo sistema \u00e8 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\u00f9 importante, funzionano e portano beneficio. Siamo convinti di aver iniziato a rilasciare software di qualit\u00e0 superiore. Inoltre, la soluzione ottenuta \u00e8 universale e pu\u00f2 essere facilmente applicata a qualsiasi progetto che necessita di organizzare test automatizzati su database Oracle.<\/p>\n

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

        Scrivete nei commenti se ci sono aspetti su cui dovremmo concentrarci in futuro o domande che richiedono approfondimenti.<\/i><\/p>\n

        Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

        Continuiamo a scrivere su questo?<\/h2>\n