Cos'è il test unitario?
Ciao a tutti, abbiamo scritto un piccolo articolo sulla nostra esperienza in Unit Testing con il mio compagno di squadra Fatmagul Polat . Buona lettura :)
Il test unitario è un metodo che verifica il comportamento di un software eseguendolo in isolamento da tutte le dipendenze della sua unità più piccola. I test unitari ci consentono di verificare il comportamento del codice che scriviamo scrivendo codice e poiché è la parte più piccola testabile del software, i test unitari sono sviluppati dagli sviluppatori.
Cos'è TDD?
Il Test driven Development è una pratica di cui abbiamo sentito parlare spesso negli ultimi anni e che sta iniziando a diffondersi. Quello che sostanzialmente dice è che il suo test deve essere scritto prima di scrivere il codice dell'applicazione.
Perché sviluppiamo unit test e vantaggi?
Ci sono molti vantaggi nell'essere in grado di scrivere test unitari, 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 scrivendo unit test per lo sviluppo. Questo processo ci porterà a pensare più intensamente alle funzionalità che svilupperemo e ci consentirà di concentrarci solo sui requisiti. Iniziare a programmare direttamente 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.
Un vantaggio della scrittura di test unitari è che puoi riconoscere gli errori che possono verificarsi nella fase di sviluppo e avere l'opportunità di correggerli. Più tempo passa tra il verificarsi di un errore e il suo rilevamento, maggiore sarà il costo per risolvere l'errore. Unit Test ci aiuterà a prevenire questo aumento dei costi.
Il nostro software è in continua evoluzione e cambiamento, quindi dovremo apportare modifiche ai metodi che abbiamo scritto. Se i miglioramenti o le modifiche stanno causando un errore imprevisto, questo errore verrà rilevato dai test che abbiamo scritto in precedenza per questo codice e possiamo riconoscerlo e agire nella fase di sviluppo. Quando aggiungiamo una nuova funzionalità a una classe i cui test sono scritti, di solito ci concentriamo sul test della funzionalità aggiunta. Anche se questa nuova funzionalità funziona correttamente, potrebbe impedire a questa classe di eseguire una funzionalità che può attualmente eseguire. Non saremo sempre in grado di testare anacardi predeterminati. In tali casi, disporre di test pre-scritti delle funzionalità esistenti protegge da errori indesiderati o trascurati.
Ogni funzionalità aggiunta fa fallire i nostri test unitari esistenti e, se dobbiamo riorganizzare questi test unitari, in realtà va contro la lettera "O" dei principi SOLID, ovvero il nostro metodo non è aperto al cambiamento.
Scrivere un test unitario ti incoraggia a ridurre la complessità del codice e scrivere codice di migliore qualità. Sarà molto difficile scrivere il test di metodi che sono complessi e contengono molta logica.
Ci consentirà di scrivere il nostro codice in metodi più piccoli per scrivere codice testabile, con una sola attività in ciascun metodo. Nel tempo, questi approcci creeranno per noi una cultura dello sviluppo software.
Quando testiamo i nostri codici, dobbiamo essere completamente isolati dalle dipendenze esterne, perché ciò 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 scriviamo ci consente di astrarre queste unità e progettare il codice in piccoli pezzi riutilizzabili. Esempi di dipendenze esterne sono i metodi con cui le operazioni vengono chiamate al database, l'esternalizzazione degli endpoint e così via.
Scrivendo codice verificabile, in realtà iniziamo ad applicare più principi SOLID.
I test unitari ben scritti contengono buoni esempi di quali output verranno presi quando alla funzione o al componente che stiamo esaminando vengono forniti quali input. Ci consente di vedere come funziona il codice in fase di test come un percorso felice, con esempi di quali sono gli scenari finali. Possiamo facilmente capire come reagiranno i nostri metodi esaminando i test unitari. Questi test possono essere specifici del documento per il progetto. Esaminando i test, può essere molto utile per capire come funzionano i metodi.
Come sviluppare un test unitario?
I passaggi nell'approccio TDD sono i seguenti;
1. Test unitario di sviluppo.
2. Il test fallisce.
3. Il test è codificato per avere successo.
4. Il test avrà esito positivo.
5. Viene eseguito il refactoring del codice.
Prima di iniziare questi passi, è necessario fare una dichiarazione delle classi e dei metodi di cui scriveremo il test. Per prima cosa, dovremmo scrivere il test dei metodi e poi vedere che questo test ha avuto esito negativo, 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 miglioramento che apportiamo affinché un metodo di test abbia successo può causare il fallimento di altri test. In questo caso, eseguiremo il refactoring del codice e completeremo il processo dopo che i test avranno nuovamente esito positivo.
Oltre all'approccio TDD, iniziamo a scrivere metodi di unit test nel tradizionale processo di sviluppo del software.
Per riassumere;
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 nostro scopo ci porterà molte cose. In questo modo, avremo una cultura di sviluppo del codice di migliore qualità provando a scrivere codice verificabile. Dovrebbe aiutarci a riconoscere gli errori nella fase iniziale anticipando come un miglioramento nel nostro codice influisce su altri comportamenti e dove potremmo ottenere errori.
Nel nostro prossimo articolo, cercheremo di spiegare come sviluppiamo metodi di unit test e spieghiamo i relativi processi campionandoli. Arrivederci
I nostri indirizzi email per eventuali feedback e suggerimenti:
Berkin — [email protected] Fatmagül — [email protected]
Link all'articolo turco :

![Che cos'è un elenco collegato, comunque? [Parte 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































