Test,TDD... Un approccio al Collaudo del Software.
Published: 2022-10-24 21:45:19

**Breve Panoramica**
---

Nel mondo lavorativo attuale, quando ci approcciamo allo sviluppo software ci concentriamo all'inizio ad apprendere le metodologie o gli strumenti adatti a supportarci nel progettare e sviluppare un software, o in senso più ampio, una soluzione digitale. 

Una volta appresi i concetti e fatta una discreta esperienza ci chiediamo domande del tipo:
_Quali sono le tecnologie maggiormente vantaggiose per il nostro caso d'uso, e quali no? Quale linguaggio di programmazione mi conviene usare? Quali framework? Vantaggi e svantaggi? E così via..._

Da ormai diversi decenni le attività di costruzione e sviluppo di un sistema informativo, sono aumentate a dismisura grazie alla sempre maggiore esigenza di sicurezza e robustezza delle soluzioni IT. Le aziende e le organizzazioni, che siano esse di prodotto o di servizio, spingono sempre di più a migliorare il processo di collaudo dei loro prodotti e servizi digitali.

Il Collaudo del Software (**Software Testing**) oggi è un aspetto molto vitale e strategico, soprattutto con la crescita e la complessità delle soluzioni di digitalizzazione e automazione dei vari processi produttivi, facendo emergere sempre di più l'esigenza di creare e sviluppare robuste attività per certificare quanto sia solido un software, e allo stesso tempo minimizzare il più possibile la presenza di spiacevoli difetti (i famosi bug).

Facendo qualche esempio , se pensiamo alla sicurezza informatica tutto ciò è vitale per cercare di ridurre al minimo eventuali rischi di **Data Breach**, ossia la violazione dei dati di chi utilizza il software o dei loro clienti.
Il rischio è la possibilità che vengono trasferiti a sistemi non autorizzati, o addirittura rubati per scopi commerciali o fraudolenti.


Per cercare una definizione precisa possiamo citare direttamente lo standard **ANSI / IEEE numero 1059**, che dichiara l'attività del Software testing come:

> _"Il processo di analisi di un software per rilevare le differenze quello che è stato sviluppato / prodotto , e ciò che effettivamente stato richiesto (ovvero difetti/errori/bug) e per valutare e validare le funzionalità sviluppate."_

---



Il concetto di **Test**, in parole semplici, è l'esecuzione di un programma eseguito con il fine di identificare eventuali lacune, errori o requisiti mancanti in contrasto con i requisiti reali.

Tutto ciò fa parte di un processo di valutazione del sistema, con lo scopo di scoprire se quest'ultimo soddisfa o meno i requisiti specificati da chi ne beneficerà. 





**Principali tecniche di collaudo del software**
---


Per dare meglio un po' di contesto, per certificare la qualità di un sistema informativo esistono due macro categorie di attività (purtroppo non possiamo essere esaustivi). 

**Fase di Collaudo del Software a basso livello**
Qui abbiamo la parte più importante dal punto di vista degli sviluppatori software, le due categorie sono chiamate:

1. Unit test (Test unitari) 
2. Test di integrazione

Proviamo a descrivere brevemente:




Unit Test:
Gli Unit Test sono Test che servono a collaudare le singole parti di un particolare software. Le possiamo chiamare moduli, funzioni, sottoprogrammi, classi o unità. Lo scopo di questi test, che sono spesso eseguiti dallo stesso programmatore, è quello di dimostrare l'effettiva operatività e funzionamento dei componenti soggetti alle varie "prove" di funzionamento.
Gli Unit Test rilevano gli errori già durante la fase di sviluppo, vengono di solito automatizzati ed eseguiti in serie. Qui c'è quindi la parte più delicata dell'intero processo di collaudo.



Test di integrazione:
I test di integrazione vengono effettuati quando c'è bisogno di verificare lo scambio di messaggi tra componenti diversi. Il test si concentra sullo sviluppo di interfacce di comunicazione esposte dai componenti coinvolti, e serve a dimostrare che i risultati emersi durante la comunicazione e lo scambio di messaggi tra tutti i processi siano corretti e soprattutto coerenti.



**Fase di collaudo del software ad alto livello**

Qui vengono raggruppate tutte le attività che riguardano i test di sistema e quelli di accettazione. 
Qui i programmatori di solito non sono intervengono direttamente, ma a volte collaborano con le diverse figure professionali che si occupano di questo lavoro. 
Ad esempio i Test Engineer, o i Test Manager che lavorano affianco ad altre figure tipo i Quality Manager o Product Manager.
Il cliente invece si occupa di eseguire i test test **UAT**(User Acceptance Testing). 
Essi sono un insieme di specifiche che servono a certificare se effettivamente i requisiti richiesti dalla soluzione sono stati implementati correttamente.

Ora cerchiamo di descrivere come poter sviluppare e definire i vari Test Unitari, in questo caso ci viene in soccorso una delle tecniche più utilizzate, soprattutto nel mondo delle metodologie 
Agile, il TDD (Test Driven Development). 


---

**TDD?**
Cosa significa esattamente Test Driven Development?

Il significato di fondo non è molto difficile da capire. In pratica quando si progetta un qualsiasi componente software , si parte scrivendo e pianificando prima gli Unit Test da scrivere e poi il codice che rispetterà i test specificati.
Nello sviluppo basato su test, il programmatore crea costantemente casi di test unitari prima dello sviluppo dei componenti , metodi o funzioni stesse.

I vantaggi per usare questa metodologia sono molteplici.
Può essere una buona idea iniziare a lavorare con la metodologia TDD quando:

---


1.C'è un'alta difficoltà a testare parti di un software già esistente. Basti pensare ad esempio ad un software monolitico, oppure a grossi sistemi che hanno tante integrazioni differenti, e magari ricorre spesso l'esigenza di conoscere e "simulare" i dati che il sistema esterno gestisce e ci invia, per replicare effettivamente tutto il flusso di comunicazione.

2.Mancanza di budget , o poche risorse a disposizione nel reparto testing/collaudo.

3.Una maggior facilità nell'addestrare gli sviluppatori a scrivere codice robusto e che funzioni nel miglior modo possibile (vale la pena ricordare che un software con 0 bug non esiste)


---
**Come fare TDD?**

Il funzionamento del TDD è semplice.
Scriviamo test e codice della funzionalità fino a quando non troviamo un caso errato.
Gli Unit Test e il componente si scrivono in modo sequenziale, partendo ovviamente dai Test che semplicemente **guidano** la funzionalità da testare.

Tutto ciò viene eseguito grazie ad un processo iterativo e costante. 
Proviamo di seguito a schematizzare i passi che ciclicamente vengono svolti durante lo sviluppo:

1.Scriviamo un test per collaudare un nuovo comportamento (funzionalità) da programmare, iniziando dall'esempio più semplice che ci viene in mente. Se tutto va bene passiamo poi al seguente test.
Appena scriviamo un test che è soddisfatto dal codice esistente, passiamo al secondo test e così via... fino a quando riceviamo un esito negativo dal programma di Unit Testing.

2.Qui ci adoperiamo a modificare il codice del programma, aggiungendo la funzionalità minima possibile fino a quando il nostro programma che rileva gli Unit test, non ci avvertirà che l'ultimo test scritto è conforme al codice che abbiamo modificato, insieme ai test scritti precedentemente.

3.Prima di proseguire e aggiungere ulteriori casi di test, come passaggio ulteriore si ripulisce il codice (o come si dice in lingua inglese facciamo il famigerato Refactoring), rimuovendo ripetizioni e casi di duplicazione del codice.

In questa fase, ovviamente, non aggiungiamo nessuna nuova funzionalità perché quest'ultima non sarà mai coperta da un Test associato. 
Dobbiamo ricordarci che non possiamo mai scrivere un nuovo metodo senza prima scrivere il suo test.
L'obiettivo di questa "pulizia" è quella di rendere il codice semplice e il più possibile comprensibile.

---

**Strumenti in Java**

Nel mondo Java ad esempio esistono diversi strumenti per sfruttare le tecniche di TDD, noi ne citiamo due:

1. JUnit
2. Mockito

**JUnit**
JUnit è il framework di riferimento per implementare gli Unit testing in Java e ovviamente il TDD. 
JUnit è stato ideato da Kent Beck insieme ad Erich Gamma, due guru e pionieri del mondo Java. 
Il primo anche uno dei firmatari della metodologia di sviluppo Agile del software.

**Mockito**
Mockito è un framework di test open source per Java. 
Esso consente la creazione di oggetti contenete dati sintetici (o di prova) dei dati reali, guidando in modo più realistico possibilita la fase degli unit test automatizzati. 
Molto utile se lavoriamo con sistemi d'integrazione e abbiamo bisogno di riprodurre e simulare i dati.

**Link utili**
---
[Esempio utilizzo base di JUnit](https://examples.javacodegeeks.com/core-java/junit/junit-hello-world-example/)

[Esempio utilizzo base di Mockito](https://www.tutorialspoint.com/mockito/mockito_first_application.htm)

[TDD esercitazione String Calculator](https://osherove.com/tdd-kata-1)