Il documento fornisce un'analisi approfondita sull'importanza e le linee guida per la creazione di unit test nelle applicazioni, enfatizzando la necessità di testare il codice per garantire che soddisfi i requisiti e riduca il rischio di bug. Vengono discussi vari framework di testing, come MSTest, e le migliori pratiche per la scrittura di test efficaci, inclusi suggerimenti su nomi e tempi per la loro esecuzione. Infine, si accenna al code coverage come indicatore della salute del codice e obiettivi futuri per i progetti di testing.

1. Unit Test
“If it ain't tested, it's broken” - Bruce Eckel
Approfondimento e linee guida sulla
creazione di Unit Test nelle applicazioni

2. Agenda
o Definizione di UnitTest
o Perchè fare UnitTest
o Framework per Unit Test
o Esepio
o Dal esempio al mondo reale
o Implementazione Domain Model
o Dal mondo reale alla nostra realtà
o Guide Line
o Build
o Code Coverage
o Obbiettivi
Settembre 2011Unit Test
2

3. Settembre 2011Unit Test
3
Unit Test
Uno Unit Test è un test che verifica il corretto funzionamento di una
unità funzionale (ad esempio un metodo) del sistema.
•Ripetibile
•Automatico
•Indipendente
•Veloce
Unit Test non individua l'assenza di errori ma ne evidenza la presenza

4. Settembre 2011Unit Test
4
Perché fare Unit Test?
Test come Verifica
Verifichiamo che il codice sia aderente ai requisiti.
Test come Confidenza
I requisiti non sono scolpiti nella roccia "Change Happens" quando
cambiano o quando facciamo refactoring ci segnalano eventuali
errori.
I test sui bug ci aiutano ad evitare i bug di regressione.
Test come Specifica
Ti aiuta a capire se le specifiche sono complete ragionando sui casi
limite e a colmarle quando mancano.
…

5. Settembre 2011Unit Test
5
Perché fare Unit Test?
Test come Buon Design
Se è difficile o impossibile testare una cosa vuol dire che il design
non è buono. Probabilmente l'accoppiamento tra i componenti è alto
o il componente ha più responsabilità di quelle che dovrebbe avere.
Test come Banco di Prova
Ti permette di verificare porzioni di codice difficili da debuggare
perché inseriti in contesti complessi facendoti risparmiare tempo.
Test come Documentazione
Leggendo i test si ha una idea di come il componente possa essere
utilizzato.

6. Settembre 2011Unit Test
6
In pratica…
Per fare test utilizzo un framework
- MsTest
- MbUnit
- NUnit
La maggior parte dei framework di test si basa sulle Asserzioni
Cosa posso Asserire:
- A partire da un determinato input avrò un determinato output
- A partire da un input avrò una determinata eccezione
- Una determinata istruzione verrà richiamata

7. Settembre 2011Unit Test
7
MsTest
Framework di testing integrato in Visual Studio 2010.
Consente di creare Unit Test, Web Test, Load Test e CodedUi Test.
Le classi sono marcate con l’attributo TestClass i metodi
con TestMethod e le asserzioni vengono fatte con la classe Assert.
ClassInitialize ClassCleanup vengono chiamati rispettivamente
all’inizio e alla fine dell’esecuzione di test in una classe e
TestInitialize TestCleanup prima e dopo l’esecuzione di un
metodo.

8. Settembre 2011Unit Test
8
Il mio primo Test
Requisiti
Il conto corrente ha un saldo che riporta il denaro attualmente
depositato.
Sul conto corrente posso prelevare o depositare denaro.
Non posso prelevare più di quello che ho sul conto.
Quando il conto corrente viene creato il saldo è 0.

9. Settembre 2011Unit Test
9
Dal primo test -> al Mondo Reale
Quando passiamo da un esempio al mondo reale quello che succede
è che la complessità aumenta.
Ci accorgiamo quindi che dobbiamo testare molte cose e testare
alcune di queste diventa difficile.
Design for testability
Progettare bene una applicazione significa più facilità nello
scrittura dei test.
Principi (Basso Accoppiamento, Alta Coesione, SOLID, ecc)
Pattern (Domain Model, Inversion of control, ecc)
Priorità nei test
I test hanno un costo
Devo testare prima le parti più critiche e più importanti

10. Settembre 2011Unit Test
10
Dal Mondo Reale -> alla nostra realtà
Prima di vedere i test applicati sulle nostre applicazioni abbiamo
bisogno di aprire una parentesi parlando di come è cambiato il modo
di implementare il pattern Domain Model.
Requisiti
Quando un cliente viene messo in black list bisogna indicarne il
motivo e congelare tutti gli ordini.

11. Settembre 2011Unit Test
11
Domain Model Anemico
Presentation
Business Logic

12. Settembre 2011Unit Test
12
Domain Model
“An object model of the domain that incorporates both behaviour and data.”
POEAA – Martin Fowler
Insieme di classi correlate tra loro in un grafo che rappresentano il dominio di
nostro interesse, ordini di vendita, tubi, farmaci, spedizioni …
• Focalizzando l’attenzione su
• Dati (proprietà)
• Comportamento (metodi)

13. Settembre 2011Unit Test
13
Domain Model NON Anemico
Presentation
Business Logic
Domain

14. Settembre 2011Unit Test
14
Guide Line - Cosa
Cosa dobbiamo testare?
Nella maggior parte della applicazioni che stiamo realizzano abbiamo
scelto di utilizzare il Domain Model.
Il DOMINIO è quindi la parte del nostro software che:
• Contiene tutta la logica di Business
• È la parte più facile da testare
Cosa non va testato?
Teoricamente niente ma in realtà
• Proprietà vuote
• Dto non hanno comportamento

15. Settembre 2011Unit Test
15
Guide Line - Come
Come dobbiamo testare?
• Test brevi
• Alta leggibilità
– Se fallisce il test devo capire subito il motivo
• Manutenibilità
• Testare una cosa sola
I test devono essere
• Ripetibile
• Automatico
• Indipendente
• Veloce

16. Settembre 2011Unit Test
16
Guide Line - Quando
Quando fare Test?
• Durante lo sviluppo della funzionalità stessa
Come gestire i costi
• Prima di iniziare a fare test il Gestore di Progetto e il Responsabile
Tecnico devono esserne a conoscenza.
• Aver creato da subito una buona architettura consente di avere
costi sulla creazione dei test inferiori.

17. Settembre 2011Unit Test
17
Guide Line - Naming
Quali Naming Guideline ci sono?
• Nome di progetto Progetto.Test
• Nome delle calssi ClasseTest
• Nome del metodo da testare
Metodo_ Scenario _ RisultatoAtteso
• I test sullo stesso metodo sono raggruppati in region

18. Settembre 2011Unit Test
18
Domain scenario
Uno scenario di test è un’istanza del dominio che rappresenta il
maggior numero possibile degli stati (scenari) che le singole entità
possono assumere.
Quando
Il dominio è complesso e le entità sono strettamente connesse.
Perché
• Scrivere test più velocemente
• Rendere i test più leggibili
Come
Lo scenario ideale deve essere credibile, complesso, e facile da
usare.

19. Settembre 2011Unit Test
19
Build
La build è l’indicatore di salute del progetto
L’esecuzione dei test viene automatizzata nell’ambiente di Build
tramite un processo di Continus Integration.
Quando una build si rompe tutto il team deve concentrarsi sul
risolvere il problema.
Risulta importante che siano state rispettate le caratteristiche di test:
• Ripetibile
• Automatico
• Veloce

20. Settembre 2011Unit Test
20
Code coverage
Il code coverage è la misura che descrive la percentuale del codice
sorgente che è stato testato in un programma.
É un indicatore e quindi va contestualizzato e interpretato ma
fornisce una buona indicazione.
In MsTest vengono conteggiate le righe che vengono eseguite
durante l’esecuzione dei test.

21. Code coverage
Possiamo vedere le linee non coperte dai test
Il code coverage viene analizzato durante l’esecuzione della build.
Settembre 2011Unit Test
21

22. Report di Qualità
Settembre 2011Unit Test
22

23. Settembre 2011Unit Test
23
Obbiettivi
In Pico nei prossimi giorni verrà inserito il documento con gli
Obbiettivi di code coverage da raggiungere per ogni progetto.

24. Settembre 2011Unit Test
24
Fine
Work Item 39773
Firmate il foglio
Rispettate gli obbiettivi