Cos'è il test unitario?

Mar 04 2023

Ciao a tutti, abbiamo scritto un piccolo articolo sulla nostra esperienza in Unit Testing con il mio compagno di squadra Berkin Ergürbüz. Buona lettura a tutti Il test unitario è un metodo che verifica il comportamento della più piccola unità testabile di un software eseguendolo in isolamento da tutte le sue dipendenze.

Ciao a tutti, abbiamo scritto un piccolo articolo sulla nostra esperienza in Unit Testing con il mio compagno di squadra Berkin Ergürbüz .

Buona lettura a tutti

Il test unitario è un metodo per verificare il comportamento della più piccola unità di software testabile eseguendola in isolamento da tutte le sue dipendenze. I test unitari ci consentono di verificare il comportamento del codice che scriviamo riscrivendo il codice.Poiché è la parte più piccola testabile del software, i test unitari sono sviluppati dagli sviluppatori di software.

CHE COS'È TDD?

Il Test Driven Development è una pratica di cui abbiamo sentito parlare spesso negli ultimi anni e che ha iniziato a diffondersi. Fondamentalmente quello che dice è che il test deve essere scritto prima di scrivere il codice dell'applicazione.

Perché scriviamo test unitari e cosa ci guadagna?

Poter scrivere unit test ha molti vantaggi, proveremo a parlarne.

Lo sviluppo con l'approccio TDD richiede una revisione approfondita dei requisiti o della progettazione prima che venga scritto qualsiasi codice funzionale. Iniziamo lo sviluppo scrivendo unit test. Questo processo ci porterà a riflettere maggiormente sulla funzionalità che svilupperemo e ci consentirà di concentrarci solo sui requisiti. Iniziare direttamente a programmare può rendere un po' più difficile per noi concentrarci sulla progettazione e sul flusso del codice durante lo sviluppo. Questo processo ci aiuterà a fare meno errori e a scrivere codice più semplice e pulito concentrandoci solo sui requisiti.

Uno dei vantaggi di essere uno scrittore di unit test è quello di poter notare gli errori che possono verificarsi durante la fase di sviluppo e di avere l'opportunità di correggerli. Più tempo passa tra il verificarsi di un errore e il suo rilevamento, maggiore è il costo per la risoluzione dell'errore, Unit Test ci aiuterà a evitare che questo costo aumenti.

Il nostro software è in una struttura in continua evoluzione e cambiamento, per questo motivo avremo bisogno di apportare modifiche ai nostri metodi che abbiamo scritto. Se i miglioramenti o le modifiche apportate causano un errore imprevisto, questo errore verrà rilevato dai test che abbiamo scritto in precedenza per questo codice e possiamo renderci conto di questa situazione durante la fase di sviluppo e intraprendere le azioni necessarie. Quando aggiungiamo una nuova funzionalità a una classe i cui test sono scritti, di solito ci concentriamo sui test della funzionalità aggiunta. Anche se questa nuova funzionalità funziona correttamente, potrebbe impedire a questa classe di soddisfare una funzionalità che può soddisfare nel suo stato attuale. Non sempre ci sarà possibile testare i casi prestabiliti. In tali casi, disporre di test pre-scritti delle funzionalità esistenti protegge da errori indesiderati o trascurati.

Ogni funzionalità aggiunta fa fallire i nostri unit test esistenti e, se dobbiamo riorganizzare questi unit test, infatti, la lettera " O" dei principi SOLID, ovvero il nostro metodo è aperto allo sviluppo ed è contrario al principio di essere chiuso al cambiamento.

La scrittura di unit test incoraggia la riduzione della complessità del codice e la scrittura di codice di migliore qualità. Sarà molto difficile scrivere test di metodi complessi e che contengano molta logica.

Per scrivere codice testabile, ci consentirà di scrivere il nostro codice in metodi più piccoli e con una sola attività in ciascun metodo. Nel tempo, questi approcci ci consentiranno di creare una cultura di sviluppo software per noi.

Mentre stiamo testando i nostri codici, dobbiamo essere completamente isolati dalle dipendenze esterne perché l'argomento che ci interessa è il codice nell'unità che vogliamo testare. Non siamo interessati al comportamento delle dipendenze esterne. La necessità di testare in modo indipendente e isolato dai pezzi di codice da cui dipendono le unità che stiamo testando ci consente di astrarre queste unità e di progettare il codice in piccoli pezzi riutilizzabili. Come esempio di dipendenze esterne; metodi, endpoint di origine esterna, ecc.

Scrivendo codice verificabile in realtà iniziamo ad applicare di più i principi SOLID.

Come scriviamo un test unitario?

Le fasi dell'approccio TDD sono le seguenti;

1. Il test è sviluppato.

2. Il test fallisce.

3. La codifica viene eseguita in modo che il test abbia esito positivo.

4. Il test ha esito positivo.

5. Viene eseguito il refactoring del codice.

Prima di iniziare questi passaggi, è necessario dichiarare le classi ei metodi per i quali scriveremo il test. Dobbiamo prima scrivere il test dei metodi, quindi vedere che questo test fallisce, codificare il metodo pertinente e continuare il processo dopo che il test ha avuto successo.

Dopo aver completato questi processi per i nostri metodi esistenti, eseguiamo tutti i nostri test e ci aspettiamo che i nostri metodi di test funzionino correttamente. Il nostro sviluppo affinché un metodo di test abbia successo può causare il fallimento di altri test. In questo caso, refactoring del codice, completiamo il processo dopo che i test hanno avuto successo.

A parte l'approccio TDD, iniziamo a scrivere dopo aver scritto il metodo dei test unitari nel tradizionale processo di sviluppo del software.

In sintesi;

Alla fine della giornata, lo scopo dei test unitari non dovrebbe essere solo quello di dire che abbiamo test unitari nel nostro progetto. Scrivere metodi di unit test che servono davvero al suo scopo ci darà molti vantaggi. Pertanto, provando a scrivere codice verificabile, avremo una cultura di sviluppo del codice di migliore qualità. Dovrebbe servire a rilevare gli errori nella fase iniziale prevedendo in che modo un miglioramento nel nostro codice influisce su altri comportamenti e dove possiamo ottenere errori.