Introduzione al testing

1. Dot Net Marche 6° Workshop – 27 giugno 2008 Introduzione al testing

2. Agenda • Unittesting, introduzione • Fixture • Struttura di un test xUnit • Test Doubling • Test Di database

3. Verificare la qualità generale del software Trovare bug nelle applicazioni Verificare le specifiche Verificare l’integrazione tra sistemi Test di regressione … Software Testing

4. Tipologie di test

5. Automatizzabile Scritto nello stesso linguaggio del codice Supportato da framework standard Supporto fondamentale per refactoring e cicli di vita agili Tecnologie standard, pattern e linguaggio comune (www.xunitpattern.org) UnitTesting

6. Test in 4 fasi [FourPhase Test] • Setup (viene impostata la situazione iniziale) • Exercise (si interagisce con il SUT) • Verify (si verificano gli output con asserzioni) • Teardown (ripristino condizioni iniziali) • Test automatizzati tramite tool a riga di comando e con interfaccia • Integrazione con il sistema di sviluppo FrameworkxUnit

7. Classe contenente test Anatomia di un test nUnit • TestFixtureSetUp • TestSetUp • Test1 • TearDown • TestSetUp • Test2 • TearDown • TestFixtureTearDown Sharedfixturesetup Sharedfixturecleanup Freshfixturesetup Freshfixturecleanup

8. Automatizzato Indipendente dagli altri test Focalizzato “single assertion test” Robusto Veloce nell’esecuzione Ripetibile Le qualtà di un buon test • Eseguito frequentemente • Eseguito automaticamente

9. Il codice dei test fa parte del progetto e non è meno importante del codice sottoposto a test I test vanno rifattorizzati e la qualità del codice deve essere tenuta alta È necessario spendere tempo per creare buoni test Avere buoni test ripaga nel lungo termine I test sono codice “first class”

10. FreshFixture: ricreare le condizioni ad ogni test • Transiente, al termine del test viene eliminata • Persistente, rimane al termine del test • SharedFixture: una stessa fixture viene riutilizzata per differenti test Fixture • Tutto ciò che deve essere fatto per creare le precondizioni di test del SUT

11. Fixture – FreshTransient Setup Exercise Fixture Verify TearDown GarbageCollector

12. Fixture – Freshpersistent Setup Exercise Setup Fixture Verify Exercise Fixture TearDown Verify TearDown • Test non ripetibili • Interazione tra i test

13. Fixture – Cleanup Setup Exercise Fixture Verify TearDown Cleanup • È necessario rimuovere manualmente la fixture nel teardown

14. Fixture – CleanupLazy Setup Exercise Setup Fixture Cleanup Verify Exercise Fixture TearDown Verify TearDown • Si può posticipare la rimozione della fixture al momento in cui è necessaria

15. Fixture – Shared Setup Exercise Exercise Fixture Exercise Verify Verify Verify TearDown TearDown TearDown • Lafixture è unica per una serie di test • Aumentare la velocità di esecuzione • Rischio di interdipendenza

16. Single assertion Test Le asserzioni debbono essere chiare Usare nomi di test significativi Asserzioni

17. Delta Assertion: in caso di sharedfixture Confronti esterni: in caso di necessità di veirifica di molti dati (Es. File) ExpectedObject: Viene creato un oggetto che rappresenta il risultato atteso Favorire interfacce fluenti che rendono le asserzioni più leggibili Asserzioni

18. Un piccolo esempio

19. Componenti difficili da testare a causa di dipendenze (Database, altre librerie, etc) Componenti dipendenti da un ambiente esterno (network, webservice, etc) Test lenti a causa di interazione con componenti esterni poco performanti Test Double

20. Il SUT dipende da un componente esterno DOC (Depend-onComponent) Il DOC è al di fuori del nostro controllo (Network, WebService) oppure semplicemente difficile da impostare (Database, FileSystem) Test Double FIXTURE Setup Exercise SUT DOC Verify TearDown

21. Per risolvere i problemi precedenti si può sostituire il SUT con un componente fittizio, creato appositamente per il test, e denominato “Test Double” Test Double FIXTURE Setup Exercise SUT Test Double DOC Verify TearDown

22. Differenti tiplogie di test double

23. Si voglia testare un componente che, dati gli ordini dell’ultimo mese, esegua delle complesse regole di business e spedisca una mail a seconda del risultato. Un esempio di Test Double FIXTURE DB Setup Exercise SUT Verify Mail TearDown

24. Alternativo al test double, agire indirettametne sul SUT manipolando il DOC • Impostare la fixture • DataBase: Script di popolazione • DataBase: DataLoader • File System: Creare i file di input • Verificare l’output del sut agendo sul DOC • Asserzioni sul contenuto del DB • Confronto di file con ExpectedObject Back DoorManipulation

25. Test di stored procedure Test del Data Access Layer Test dei mapping di un ORM Test di performance Le problematiche maggiori dei test di Database sono collegate all’impostazione della fixture ed alla sua rimozione I rischi sono di avere test erratici, non ripetibili, fragili e interdipendenti Test di Database

26. Come gestire i test dei database

27. Creazione del database di sandbox Creare un database in recovery mode simple (evita il transaction log) Copiare la struttura dal database master Esempio di test di database

28. Creare un preloader che funziona con bcp e BULK INSERT Utilizzare il TransactionScope per creare transazioni automatiche Creare singole classi di test raggruppate per Fixture, dove la fixturenon è altro che una serie di file con i dati da precaricare Utilizzare la gestione automatica delle transazioni Esempio di test di database

29. Il preload cancella tutto il contenuto di alcune tabelle e le precarica. Viene fatto all’inizio del test e costituisce una SharedFixture • Prima di ogni test viene creato un TransactionScope, tutto il codice che accede al db è transazionale • Nel TearDown del singolo test viene annullata ogni modifica effettuando il rollback della transazione. Esempio di test di database

30. Esempio di test su db

31. Scrivere codice favorendo la possibilità di eseguire test Uso intensivo di IoC e DI Design fortestability DBL DOC DOC DBL DOC DOC I I SUT SUT I I DOC DOC DBL DOC DBL DOC

32. Test di metodi privati Design fortestability PROTECTED PRIVATE TSS PUBLIC PROTECTED

33. Test DrivenDevelopment Red -> Green -> Refactor Design fortestability

34. Domande??