24
Unit Test “If it ain't tested, it's broken” - Bruce Eckel Approfondimento e linee guida sulla creazione di Unit Test nelle applicazioni
| Date post: | 07-Aug-2015 |
| Category: |
Software |
| Upload: | roberto-cappelletti |
| View: | 201 times |
| Download: | 0 times |
Unit Test
“If it ain't tested, it's broken” - Bruce Eckel
Approfondimento e linee guida sulla creazione di Unit Test nelle applicazioni
Agendao Definizione di UnitTesto Perchè fare UnitTesto Framework per Unit Testo Esepioo Dal esempio al mondo realeo Implementazione Domain Modelo Dal mondo reale alla nostra realtào Guide Lineo Buildo Code Coverageo Obbiettivi
Settembre 2011Unit Test
2
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
Settembre 2011Unit Test
4
Perché fare Unit Test?
Test come VerificaVerifichiamo che il codice sia aderente ai requisiti.
Test come ConfidenzaI 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 SpecificaTi aiuta a capire se le specifiche sono complete ragionando sui casi limite e a colmarle quando mancano.
…
Settembre 2011Unit Test
5
Perché fare Unit Test?
Test come Buon DesignSe è 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 ProvaTi permette di verificare porzioni di codice difficili da debuggare perché inseriti in contesti complessi facendoti risparmiare tempo.
Test come DocumentazioneLeggendo i test si ha una idea di come il componente possa essere utilizzato.
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
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.
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.
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 testabilityProgettare 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 testI test hanno un costoDevo testare prima le parti più critiche e più importanti
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.
Settembre 2011Unit Test
11
Domain Model Anemico
Presentation
Business Logic
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)
Settembre 2011Unit Test
13
Domain Model NON Anemico
Presentation
Business Logic
Domain
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
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
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.
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
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.
QuandoIl dominio è complesso e le entità sono strettamente connesse.
Perché• Scrivere test più velocemente• Rendere i test più leggibili
ComeLo scenario ideale deve essere credibile, complesso, e facile da usare.
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
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.
Code coverage
Possiamo vedere le linee non coperte dai test
Il code coverage viene analizzato durante l’esecuzione della build.
Settembre 2011Unit Test
21
Report di Qualità
Settembre 2011Unit Test
22
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.
Settembre 2011Unit Test
24
Fine
Work Item 39773
Firmate il foglio
Rispettate gli obbiettivi
