Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Ingegneria del software A.

Transcript

1 Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Ingegneria del software A Testing Michele Tomaiuolo

2 Qualità interne ed esterne Le qualità su cui si basa la valutazione di un sistema software possono essere: Interne, riguardano le caratteristiche legate allo sviluppo del software e non sono visibili agli utenti Esterne, riguardano le funzionalità fornite dal sistema e sono visibili agli utenti Le categorie sono legate, non è possibile ottenere qualità esterne se il sistema non gode di qualità interne 2

3 Qualità del prodotto e del processo È anche possibile valutare un sistema secondo qualità Relative al prodotto, riguardano le caratteristiche stesse del sistema e sono sempre valutabili Relative al processo, riguardano i metodi utilizzati durante lo sviluppo del software Le categorie sono legate, non è possibile ottenere qualità del prodotto se il sistema non gode di qualità del processo Product quality is process quality 3

4 Qualità esterne Correttezza: il sistema rispetta le specifiche Affidabilità (dependability): l utente può dipendere dal sistema Robustezza: il sistema si comporta in modo ragionevole anche in circostanze non previste dalle specifiche Efficienza: usa bene le risorse di calcolo Scalabilità: migliori prestazioni con più risorse Sicurezza: authentication, authorization, accounting Facilità d uso: un sistema è facile da usare se l interfaccia che presenta all utente gli permette di esprimersi in modo naturale 4

5 Valutazione delle qualità Valutazione sulla base delle specifiche Correttezza e affidabilità Robustezza: riguarda tutti i casi non trattati dalle specifiche Valutazione dei committenti Correttezza e facilità d uso Valutazione degli sviluppatori Robustezza ed efficienza 5

6 Qualità interne Verificabilità: sistema basato su modello formale Riusabilità: parti usabili per costruire nuovi sistemi Manutenibilità Riparabilità: facilitata la ricerca degli errori Evolvibilità: aggiungere nuove funzionalità al sistema Adattabilità: rispetto a cambiamenti del dominio applicativo Interoperabilità: capacità di co-operare con altri sistemi, anche di altri produttori Portabilità: può funzionare su più piattaforme hw/sw Comprensibilità: codice leggibile, documentazione Modularità: interazione tra componenti coesi 6

7 Qualità del processo Produttività, misura l efficienza del processo nei termini della velocità di consegna del sistema Tempestività, misura la capacità del processo di valutare e rispettare i tempi di consegna del sistema Trasparenza, un processo di produzione è trasparente se permette di capire il suo stato e di controllarne i passi Agilità, misura la capacità del processo di consentire la produzione in tempi ridotti (ridotto time-to-market) 7

8 Costi del software I costi del software sono spesso predominanti nei costi di un sistema Il costo del software in un PC spesso è maggiore di quello dell intero hardware Il costo del software è principalmente nel mantenimento piuttosto che nello sviluppo Uno degli obiettivi principali dell ingegneria del software è ottenere un sviluppo cost-effective prevenendo per quanto possibile i costi di manutenzione 8

9 Costo diretti Costo delle risorse per lo sviluppo (costi diretti) Costo del personale sviluppatore, spesso predominante sugli altri Costo del personale di supporto Costo delle risorse di sviluppo Materiali di consumo Altri costi generali della struttura 9

10 Costi indiretti Altri costi, più aleatori (costi indiretti) Capacità, motivazione e coordinamento del personale Complessità del sistema da realizzare Stabilità dei requisiti Caratteristiche dell ambiente di sviluppo Costo di manutenzione ed evoluzione 10

11 Evoluzione di un sistema software Il software deve evolvere perché: Non sono stati colti correttamente i requisiti I requisiti non sono inizialmente noti Cambiano le condizioni operative L evoluzione è ineliminabile per gran parte delle tipologie di sistemi, anche se i requisiti iniziali sono corretti e completi 11

12 Manutenzione Manutenzione è il processo di modifica di un sistema dopo il suo rilascio al fine di Eliminare anomalie (manutenzione correttiva) Migliorare le prestazioni o altri attributi di qualità (manutenzione perfettiva) Adattare a mutamenti dell ambiente (manutenzione adattativa) Costi della manutenzione: Spesso maggiori del 50% del costo totale del software 75% (fonte Hewlett-Packard) 70% (fonte Dipartimento della Difesa degli Stati Uniti) Manutenzione correttiva: 20% Manutenzione perfettiva: 60% Manutenzione adattativa: 20% 12

13 Dati sulla manutenzione Esperienza di Hewlett-Packard La maggior parte degli errori potrebbe essere scoperta mediante tecniche sistematiche di revisione di progetto I moduli con maggior complessità del flusso di controllo hanno maggiore probabilità di contenere errori Alcuni dati Su 10 difetti scoperti durante il test, 1 si propaga nella manutenzione Eliminare i difetti costa, in tempo, 4-10 volte per sistemi grossi e maturi rispetto a piccoli e ancora in sviluppo Il costo di rimozione degli errori aumenta con il ritardo rispetto al quale gli errori sono introdotti 13

14 Problemi più attuali Gestire sistemi vecchi ma non sostituibili (legacy system) Necessità di manutenzione adattativa Problemi dovuti alla tecnologia obsoleta Gestire l eterogeneità dei sistemi I sistemi sono sempre distribuiti e sono composti da una grande varietà di sistemi hardware e software Riduzione dei tempi di consegna C è una sempre maggiore pressione per ottenere tempi di consegna brevi 14

15 Verifica e validazione La verifica e la validazione servono per mostrare che il sistema È conforme alle specifiche Incontra i requisiti dell utente Comprende revisione e testing del sistema Il testing di un sistema richiede di eseguire il sistema su casi di test (test case) derivati dalle specifiche 15

16 Testing Le operazioni di testing possono individuare la presenza di errori nel software ma non ne possono dimostrare la correttezza -- E. Dijkstra A cosa serve il testing Verificare il comportamento del sistema in un insieme di casi sufficientemente ampio da rendere plausibile che il suo comportamento sia analogo anche nelle restanti situazioni Le operazioni di testing si suddividono in: Testing in the small, riguardano moduli singoli Testing in the large, riguardano il sistema nella sua globalità 16

17 Processo di Testing Unit testing Module testing Sub-system testing System testing Acceptance testing Component testing Integration testing User testing 17

18 Fasi di Testing (1/2) Unit testing Ogni singolo componente Module testing Ogni modulo, insieme di componenti interdipendenti Sub-system testing Integrazione tra moduli in sotto-sistemi per individuare problemi nelle interfacce tra i moduli System testing Sistema nel suo complesso, eventuali proprietà emergenti del sistema Acceptance testing Con i committenti per verificare l accettabilità del sistema 18

19 Fasi di Testing (2/2) Requir ements specification System specification System design Detailed design Acceptance test plan System integration test plan Sub-system integration test plan Module and unit code and tess Service Acceptance test System integration test Sub-system integration test 19

20 Statement test Valuta il corretto funzionamento di una porzione del codice Analizzando il suo output in relazione ad input significativi Verifica di copertura dei programmi (statement test) Un errore non può essere scoperto se la parte di codice che lo contiene non viene eseguita almeno una volta Criterio: selezionare un insieme di test T tali che, a seguito dell esecuzione del programma P su tutti i casi di T, ogni istruzione elementare di P venga eseguita almeno una volta Può essere eseguito solo conoscendo la struttura interna della porzione di codice (white-box testing) 20

21 Branch test Verifica di copertura delle decisioni (branch test) Per ogni condizione presente nel codice è utilizzato un test che produca risultato vero e falso Criterio: selezionare un insieme di test T tali che, a seguito dell esecuzione del programma P su tutti i casi di T, ogni arco del grafo di controllo di P sia attraversato almeno una volta Può essere eseguito solo conoscendo la struttura interna della porzione di codice 21

22 Branch and condition test Verifica di copertura delle decisioni e delle condizioni Per ogni porzione di condizione composta presente nel codice, sia utilizzato un test che produca il risultato vero e falso Criterio: selezionare un insieme di test T tali che, a seguito dell esecuzione del programma P su tutti i casi di T, ogni arco del grafo di controllo di P sia attraversato e tutti i possibili valori delle condizioni composte siano valutati almeno una volta Produce un analisi più approfondita rispetto al criterio di copertura delle decisioni Può essere eseguito solo conoscendo la struttura interna della porzione di codice 22

23 Testing in the large Il white-box testing è impossibile per sistemi di grandi dimensioni Il sistema è visto come una scatola nera (black-box testing) e si vanno a verificare le corrispondenze di input e output L insieme di test da utilizzare viene selezionato sulla base delle specifiche 23

24 Esempio: fatture Problema: il sistema riceve come input una fattura di cui è nota la struttura dettagliata La fattura deve essere inserita in un archivio ordinato per data Se esistono altre fatture con la stessa data fa fede l ordine di arrivo È inoltre necessario verificare che: Il cliente sia già stato inserito in archivio e Vi sia corrispondenza tra la data di inserimento del cliente e quella della fattura, Test set: 1. Fattura con data odierna 2. Fattura con data passata e per la quale esistono altre fatture 3. Fattura con data passata e per la quale non esistono altre fatture 4. Fattura il cui cliente non è stato inserito 5. 24

25 Ispezione del software Analisi del codice per capirne le caratteristiche e le funzionalità Può essere effettuata sul codice oppure sullo pseudocodice Permette la verifica unitaria di un insieme di condizioni È soggetta agli errori di colui che la effettua Si basa su un modello della realtà e non su dati reali I due principali approcci Code walk-through Code inspection 25

26 Code walk-through Analisi informale eseguita da un team di persone 1. Opportuna selezione di porzioni del codice e valori di input 2. Simulazione su carta del comportamento del sistema Il numero di persone coinvolte deve essere ridotto Al fine di aumentare il clima di cooperazione all analisi non devono partecipare i manager Il progettista deve fornire in anticipo documentazione del codice L analisi non deve durare più di alcune ore L analisi deve essere indirizzata solamente alla ricerca dei problemi e non alla loro soluzione 26

27 Code inspection Analisi eseguita da un team di persone e organizzata come nel caso del code walk-through Mira a ricercare classi specifiche di errori Il codice viene esaminato controllando soltanto la presenza di una particolare categoria di errore, piuttosto che simulando una generica esecuzione Le classi di errori che vengono solitamente ricercate con questa tecnica sono Uso di variabili non inizializzate Loop infiniti Letture di porzioni di memoria non allocata Rilascio improprio della memoria 27

28 Program testing Program testing is the process of executing a program with the intent of finding errors -- Glen Myers, The art of Software Testing Buon test: buone probabilità di trovare errori Non può dimostrare l assenza di errori Può solo mostrare la presenza di errori Ad alto consumo di risorse e tempo Non è insolito dedicare al testing il 40% degli sforzi complessivi di un progetto 28

29 Classificazione dei test Tipi di test White box Black box test Livelli di test Unit test Integration test System test Ripetizione di test Regression test 29

30 Testabilità Qualità del software che influiscono sulla capacità di rilevare errori Osservabilità Risultato di un test raggiungibile e visibile Controllabilità Ingressi e stato di un programma devono essere controllabili prima di eseguire un test Decomponibilità Il programma deve essere diviso in parti che possano essere testate individualmente Comprensibilità L intenzione del programmatore, sul comportamento corretto del programma, deve essere disponibile per il tester Progettazione per testabilità 30

31 Test utopia In un mondo ideale, tutti i possibili percorsi di esecuzione di un programma dovrebbero essere testati Test totale di un programma: esecuzione di tutte le possibili combinazioni di comandi ed espressioni relative alle strutture di controllo Anche in piccoli programmi, il numero di percorsi in un test totale è molto ampio In molti programmi, non è noto il limite di percorsi di un test totale Nel mondo reale, bisogna selezionare il sottinsieme di percorsi del test totale con maggiore probabilità di rilevare errori nel programma 31

32 Prove matematiche Una dimostrazione matematica di un programma è una alternativa (principalmente accademica) al testing Le post condizioni devono essere verificate dato che Le precondizioni siano verificate Il programma termina Si basa su Annotazione del programma con asserzioni matematiche che riflettono il comportamento attesi dal programma Proprietà che valgono per i vari costrutti del programma Le dimostrazioni eseguite a mano avranno probabilmente più errori che il programma stesso Maggiore fiducia solo da dimostrazioni automatiche 32

33 Testing white box Usa le strutture di controllo di un programma per derivare i test case Scopo: garantire che tutti i comandi e le espressioni di un programma siano eseguiti almeno una volta Desiderata Tutti i percorsi indipendenti di una unità del programma siano eseguiti almeno una volta Tutte le derivazioni logiche siano esercitate Tutti i cicli e le strutture dati siano esercitati ai loro limiti 33

34 Basic path testing Tecnica di testing white box, che aiuta a scegliere un insieme minimo di percorsi in un programma che coprono tutte le istruzioni e condizioni Un percorso in una unità di programma è una sequenza di comandi e condizioni, dall inizio alla fine Cammino indipendente: aggiunge almeno una nuova istruzione o condizione rispetto ai cammini indipendenti già identificati Approccio complessivo 1. Tracciare un diagramma di flusso della unità 2. Astrarre il diagramma in un grafo 3. Trovare la complessità ciclomatica (diciamo n) metrica di test 4. Trovare n casi di test che seguono ciascun cammino indipendente 34

35 Complessità ciclomatica public static void P(){ // Entry while(a) { X; if (B) { if(c) Y; else Z; // p else { V; W; // q // Exit: r 35

36 Diagramma di flusso 36

37 Grafo di flusso Piccola astrazione rispetto ad un diagramma di flusso A, r A, X, B, C, Y, p, q, A, r A, X, B, C, Z, p, q, A, r A, X, B, V, W, q, A, r 37

38 Grafo di flusso 38

39 Metrica e casi di test Calcolare la metrica e trovare i casi di test sulla base della complessità Complassità ciclomatica: determinata sul grafo, usando semplici concetti della teoria dei grafi Numero di regioni del grafo di flusso, o Numero di nodi predicato + 1 Costruire un caso di test per ogni cammino indipendente Il caso di test dovrebbe seguire il controllo del percorso 39

40 Esempio: GCD int gcd(int i, int j) { int small, large, remainder; if (i <= j) small = i; else small = j; if (i <= j) large = j; else large = i; while (small > 0) { remainder = large % small; large = small; small = remainder; return large; void main() { int i, j; printf("enter two positive integers: "); scanf("%d %d", &i, &j); printf("gcd of %d and %d is %d\n\n", i, j, gcd(i,j)); 40

41 Complessità di GCD La complessità ciclomatica di GCD è 4 In generale, la complessità ciclomatica è un limite superiore per il numero di test case necessari Nella funzione GCD, è possibile coprire tutte le righe di codice con due test case Si noti che in gcd le condizioni delle due strutture di controllo sono accoppiate Cattiva programmazione! Potrebbe essere impossibile trovare dat che esercitino tutti I cammini indipendenti 41

42 Black box testing Usa l interfaccia di una unità di programma per costruire I test case Lo scopo è dimostrare che viene prodotta l uscita corretta per input validi in relazione ai requisiti funzionali Desiderata Trovare gli errori funzionali: otteniamo i risultati attesi per dati input di un metodo? Trovare errori di interfaccia: i dati sono passati correttamente tra i metodi? Trovare errori di efficienza: il metodo è abbastanza veloce? 42

43 Input per un test black box Non è realistico da un punto di vista combinatorio testare un programma su tutti i possibili ingressi Questione centrale: scelta valori d ingresso Partizionamento degli ingressi in classi di equivalenza Si ipotizza che sia sufficiente testare l unità di programma su un solo caso per classe Si includono i casi limite Tipo collezioni vuote o piene Si includono uno o più casi di input non valido Con controllo sui tipi e precondizioni lo spazio è limitato 43

44 Partizioni d equivalenza // Exchange element i and j in table public void swapelements(t[] table, int i, int j) {... Partizioni d equivalenza tutte le combinazioni di: Table Vuota, o non vuota i, j Almeno uno tra i e j fuori dai limiti Sia i che j dentro i limiti: i < j, i > j, i = j L uso di controllo dei tipi e controllo dei limiti riduce il numero di casi di test 44

45 Partizioni d equivalenza // Find the largest element in table in between from and to. // Precondition: 0 <= from <= to <= table.count-1 public int findmaxindex(t[] table, int from, int to) {... Precondizioni ben scelte riducono il numbero di test Partizioni d equivalenza tutte le combinazioni di: Table Vuota Elemento maggiore primo, ultimo o a metà in table Tutti elementi uguali from e to from e to ai limiti della tabella from = to, from = to - 1, oppure lontani tra loro 45

46 Regression testing Lo scopo del regression test è trovare errori di regressione Errori in un programma che prima era corretto, ed è stato modificato di recente Un errore di regressione è un errore che non c era Dopo la modifica di una perte P nel programma Q Testare che la parte P funzioni correttamente Testare che l intero programma Q non sia stato danneggiato dalla modifica 46

47 Annotazioni Forniscono dati su un programma Usi: Non sono parte delle istruzioni del programma stesso Informazioni per il compilatore - Per rilevare errori o sopprimere warning Elaborazione durante la compilazione o il deployment Gli strumenti software possono generare code, file XML ecc. Elaborazione durante l esecuzione Alcune annotazioni sono disponibili a runtime Le annotazioni possono essere applicate a classi, campi, metodi e altri elementi del programma 47

48 Sintassi All inizio di una riga, (per convenzione su una riga propria), può includere elementi con ) name = "Benjamin Franklin", date = "3/27/2003 class MyClass() = "unchecked") void mymethod() // name omitted, just one element named "value void mymethod() void mysupermethod() { 48

49 Documentazione // metadata in comments public class Generation3List extends Generation2List { // Author: John Doe // Date: 3/17/2002 // Current revision: 6 // Last modified: 4/12/2004 // By: Jane Doe // Reviewers: Alice, Bill, Cindy // class code goes here // metadata in ClassPreamble { String author(); String date(); int currentrevision() default 1; String lastmodified() default "N/A"; String lastmodifiedby() default "N/A"; String[] reviewers(); // Note use of array 49

50 Documentazione Dopo aver definito un tipo d annotazione, si può usare fornendo i valori // keep info for // add metadata to javadoc ( author = "John Doe", date = "3/17/2002", currentrevision = 6, lastmodified = "4/12/2004", lastmodifiedby = "Jane Doe reviewers = {"Alice", "Bob", "Cindy" // Note array notation ) public class Generation3List extends Generation2List { // class code goes here 50

51 Annotazioni per il compilatore Tre annotazioni predefinite nelle specifiche del Indica elementi non più in uso Il compoilatore genera un warning se un programma lo usa Viene documentato in Informa il compilatore che si sovrascrive un elemento della Il compilatore non genera warning deprecation: unchecked: uso di codice senza generics 51

52 Elaborazione delle annotazioni Possibile scrivere processori di annotazioni, per leggere un programma e agire a seconda delle annotazioni Generazione automatica di codice ripetitivo Occorre implementare AnnotationProcessor Java 5: apt (annotation processing tool) Java 6: funzionalità inclusa nel compilatorejavac 52

53 JUnit Caratteristiche principali Novità delle ultime versioni Test parametrici, di eccezione e temporizzati Fixture flessibili Raggruppamento ad esclusione di test Testing con Eclipse e Ant 53

54 Il vecchio JUnit Prima dell aggiunta delle annotazioni in Java 5, il framework JUnit (ver<4) aveva stabilito due convenzioni essenziali per il suo funzionamento 1. Ogni metodo scritto per funzionare come un test logico cominciava con la parola test Se un metodo cominciava così, es.testusercreate, veniva incluso nel processo di test (fixture eseguite prima e dopo) 2. Una classe veniva riconosciuta da JUnit come contenitore di test solo se estendevatestcase Un test che violava una delle due convenzioni, non veniva eseguito 54

55 Esempio JUnit (ver<4) import java.util.regex.matcher; import java.util.regex.pattern; import junit.framework.testcase; public class RegexTest extends TestCase { private String zipregex = "^\\d{5([\\-]\\d{4)?$"; public void testzipcode() throws Exception { Pattern pattern = Pattern.compile(zipRegEx); Matcher m = this.pattern.matcher("12345"); boolean isvalid = m.matches(); asserttrue("zip code wasn t validated", isvalid); 55

56 JUnit 4 JUnit 4 usa le annotazioni di Java 5 per eliminare completamente entrambe le convenzioni 1. La gerarchia di classi non è più richiesta 2. Ogni metodo che si vuole far fuzionare come test deve essere annotato come@test Static import Gli static import di Java 5 permettono di usare più facilmente i metodi della classe Assert, es. assertfalse I test non estendono piùtestcase, nè alcuna classe 56

57 Esempio JUnit 4 import java.util.regex.matcher; import java.util.regex.pattern; import org.junit.test; import static org.junit.assert.asserttrue; public class RegexTest { private String zipregex = public void verifygoodzipcode() throws Exception { Pattern pattern = Pattern.compile(zipRegEx); Matcher m = this.pattern.matcher("22101"); boolean isvalid = m.matches(); asserttrue("zip code wasn t validated", isvalid); 57

58 Vantaggio delle annotazioni Le annotazioni documentano chiaramente ciò che un metodo dovrebbe fare Non richiedono di conoscere il modello interno del framework e tutte le convenzioni In precedenza era richiesta familiarità con le convenzioni di JUnit anche solo per capire un test case Inoltre le annotazioni aggiungono altre potenzialità al processo di test 58

59 Test di eccezioni Come nelle vecchie versioni di JUnit, bisogna specificare che i test possono lanciareexception Funzionamento normale: se un test lancia una eccezione, il framework marca il test come fallito Caso particolare se si vuole testare il lancio di una certa eccezione Sull annotazione@test si può specificare il parametro expected Rappresenta il tipo di eccezione che dovrebbe venir lanciata L esempio seguente mostra il test delle eccezioni prima nella vecchia forma, e poi nella nuova, più chiara 59

60 Esempio con eccezioni (ver<4) import java.util.regex.matcher; import java.util.regex.pattern; import junit.framework.testcase; public class RegexTest extends TestCase { private String zipregex = "^\\d{5([\\-]\\d{4)?$"; private Pattern pattern; protected void setup() throws Exception { this.pattern = Pattern.compile(this.zipRegex); public void testzipcodegroupexception() throws Exception { Matcher m = this.pattern.matcher(" "); boolean isvalid = m.matches(); try { m.group(2); fail("no exception was thrown"); catch(indexoutofboundsexception e) { 60

61 Aggiornamento test di eccezioni Le vecchie versioni di JUnit richiedono un po di codice per creare un semplice test sulle eccezioni Aggiungere un blocco try/catch Invocare il fallimento del test se l eccezione non viene catturata Test di eccezioni in JUnit 4 Differenza principale: si usa il nuovo paramentoexpected È possibile aggiornare vecchi test aggiungendo l eccezione alla annotazione@test 61

62 Esempio con eccezioni import java.util.regex.matcher; import java.util.regex.pattern; import org.junit.beforeclass; import org.junit.test; public class RegexTest { private static String zipregex = "^\\d{5([\\-]\\d{4)?$"; private static Pattern public static void setupbeforeclass() throws Exception { pattern = public void verifyzipcodegroupexception() throws Exception { Matcher m = this.pattern.matcher(" "); boolean isvalid = m.matches(); m.group(2); 62

63 Test temporizzati In JUnit 4, un test può prendere un valore ditimeout come parametro Il valore ditimeout rappresenta il massimo intervallo di tempo che l esecuzione del test può impiegare Se il tempo scade, il test public void verifyfastzipcodematch() throws Exception { Pattern pattern = Pattern.compile("^\\d{5([\\-]\\d{4)?$"); Matcher m = pattern.matcher("12345"); boolean isvalid = m.matches(); asserttrue("pattern did not validate zip code", isvalid); 63

64 Test da ignorare Prima di JUnit 4, ignorare un test sbagliato o incompleto era possibile in maniera piuttosto rozza Alterare il nome del metodo in modo da infrangere la convenzione Spesso si aggiungeva un underscore prima del nome del metodo, per indicare che il test non era da eseguire JUnit 4 ha introdotto la chiara annotazione@ignore Indica al framework di ignorare un certo metodo di test Si può anche passare un messaggio per documentare la decisione agli altri sviluppatori, altrimenti ignari dei motivi dell esclusione 64

65 Esempio di test da regular expression isn't complete public void verifyzipcodematch() throws Exception { Pattern pattern = Pattern.compile("^\\d{5([\\-]\\d{4)"); Matcher m = pattern.matcher("12345"); boolean isvalid = m.matches(); asserttrue("pattern did not validate zip code", isvalid); 65

66 Perché usare le fixture Le fixture incoraggiano il riuso, definendo del codice che deve essere eseguito prima o dopo i test Nelle vecchie versioni di JUnit ciò era implicito, sia che le fixture fossero implementate o no JUnit 4 ha reso le fixture esplicite con le annotazioni Codice fixture eseguito solo se necessario Si può specificare che certe fixture siano eseguite prima o dopo di certi test, codice riusato 66

67 Esempi di fixture Esempi Inizializzare una classe che verrà testata in modi diversi Popolare un database prima di eseguire test dipendenti dai dati In ogni caso, l uso delle fixture permette di gestire meglio i test, sfruttando logica comune Le fixture tornano utili specialmente quando molti test usano in parte la stessa logica In caso di problemi, si può analizzare il codice di setup concentrato in un solo punto, anzichè scorrere tutti i test 67

68 Fixture inflessibili Le vecchie versioni di JUnit impiegavano un modello di fixture poco flessibile L esecuzione di ogni test veniva preceduta dal metodo setup e seguita dal metodoteardown Svantaggio: metodi eseguiti più volte, una per ogni test definito Nelle versioni precedenti di JUnit era possibile specificare di eseguire una fixture solo una volta Si istanziava un oggettotestsetup nel metodosuite Ma era una operazione abbastanza scomoda Maneggiare le fixture poteva portare più grattacapi che benefici 68

69 Esempio di fixture di test (ver<4) import... public class RegexTest extends TestCase { private Pattern pattern; protected void setup() throws Exception { this.pattern = Pattern.compile("^\\d{5([\\-]\\d{4)?$"); public void testzipcodegroup() throws Exception { Matcher m = this.pattern.matcher(" "); assertequals("group(1) didn't match", "-4321", m.group(1)); public void testzipcodegroupexception() throws Exception { Matcher m = this.pattern.matcher(" "); boolean isvalid = m.matches(); try{ m.group(2); fail("no exception was thrown"); catch(indexoutofboundsexception e) { 69

70 Esempio di fixture di classe (ver<4) import java.util.regex.*; import junit.extensions.testsetup; import junit.framework.test; import junit.framework.testcase; import junit.framework.testsuite; import junit.textui.testrunner; public class RegexTest extends TestCase { private static Pattern pattern; public static Test suite() { TestSetup setup = new TestSetup( new TestSuite(OneTimeRegexTest.class)) { protected void setup() throws Exception { pattern = Pattern.compile("^\\d{5([\\-]\\d{4)?$"); ; return setup;... 70

71 Esempio di fixture di classe (ver<4)... public void testzipcodegroup() throws Exception { Matcher m = pattern.matcher(" "); boolean isvalid = m.matches(); assertequals("group(1) didn't match", "-4321", m.group(1)); public void testzipcodegroupexception() throws Exception { Matcher m = pattern.matcher(" "); boolean isvalid = m.matches(); try { m.group(2); fail("no exception was thrown"); catch (IndexOutOfBoundsException e) { 71

72 Fixture in JUnit 4 Nuovo e migliorato modello di fixture in JUnit 4 JUnit 4 usa le annotazioni per eliminare molto overhead relativo alle fixture Permette di eseguire una fixture per ogni test, per una intera classe, o non eseguirla affatto 2 annotazioni per le fixture di livello classe A livello di classe ci sono@beforeclass e@afterclass Utili per ottimizzazione (es. collegamento a DB) 2 annotazioni per le fixture di livello metodo (test) A livello di metodo (o test) ci sono@before e@after Possibile specificare dei test con una 72

73 Fixture di test import... public class RegexTest { private static Pattern public static void setupbeforeclass() throws Exception { pattern = public void verifyzipcodenomatch() throws Exception { Matcher m = this.pattern.matcher("1357"); boolean notvalid = m.matches(); assertfalse("pattern did validate zip code", public void verifyzipcodegroupexception() throws Exception { Matcher m = this.pattern.matcher(" "); boolean isvalid = m.matches(); m.group(2); 73

74 Fixture di classe import... public class RegexTest { private static Pattern public static void setupbeforeclass() throws Exception { pattern = public void verifyzipcodenomatch() throws Exception { Matcher m = this.pattern.matcher("1357"); boolean notvalid = m.matches(); assertfalse("pattern did validate zip code", public void verifyzipcodegroupexception() throws Exception { Matcher m = this.pattern.matcher(" "); boolean isvalid = m.matches(); m.group(2); 74

75 Fixture multiple Si possono specificare più fixture per un test case Le annotazioni di JUnit4 possono essere ripetute, marcando diversi metodi Ma non si può specificare l ordine di esecuzione Vengono eseguite prima le fixture delle classi genitore 75

76 Test suite Meccanismo usato per raggruppare logicamente dei test ed eseguirli assieme L annotazione@suiteclasses raggruppa una lista di classi, passate come parametro, in una test suite L annotazione@runwith permette di impostare diversi esecutori di test Di solito si usasuite, già incluso nel framework Esempio che mostra come gestire le suite nelle diverse versioni di JUnit 76

77 Esempio di test suite (ver<4) import junit.framework.test; import junit.framework.testsuite; public class JUnit3Suite { public static Test suite() { TestSuite suite = new TestSuite(); suite.addtest(regextest.class); suite.addtest(parametricregextest.class); suite.addtest(timedregextest.class); return suite; 77

78 Esempio di test suite import org.junit.runner.runwith; import org.junit.runners.suite; ParametricRegexTest.class, RegexTest.class, TimedRegexTest.class) public class JUnit4Suite { 78

79 Esecuzione dei test Si può eseguire una classe di test di JUnit 4 da un IDE come Eclipse Run As JUnit test Oppure da linea di comando Eseguire la classe org.junit.runner.junitcore, passando come argomento il nome completo di una classe di test java org.junit.runner.junitcore <test class name> 79

80 Profilo d esecuzione in Eclipse 80

81 Esecuzione in Ant <!-- Define any necessary Ant properties --> <property name="src" value="./src" /> <property name="lib" value="./lib" /> <property name="classes" value="./classes" /> <property name="test.class.name" value="com.xyz.mytestsuite" /> <!-- Set up the CLASSPATH to be used by JUnit --> <path id="test.classpath"> <pathelement location="${classes" /> <pathelement location="/path/to/junit.jar" /> <fileset dir="${lib"><include name="**/*.jar"/></fileset> </path> <!-- Define the Ant task for running JUnit --> <target name="test"> <junit fork="yes" haltonfailure="yes"> <test name="${test.class.name" /> <formatter type="plain" usefile="false" /> <classpath refid="test.classpath" /> </junit> </target> 81

82 Esecuzione di più test in Ant... <!-- Define the Ant task for running JUnit --> <target name="test"> <junit printsummary="yes" haltonfailure="yes">... <batchtest fork="yes"> <fileset dir="${test.dir"> <include name="**/*test.java" /> <include name="**/test*.java" /> </fileset> </batchtest> </junit> </target> 82

83 Assert su array Nuovo metodo di assert per confrontare il contenuto di due array L esempio seguente fallisce per le differenze tra gli public void verifyarraycontents() throws Exception { String[] actual = new String[] { "JUnit 3.8.x", "JUnit 4", "TestNG"; String[] var = new String[] { "JUnit 3.8.x", "JUnit 4.1", "TestNG 5.5"; assertequals("the two arrays are not equal", actual, var); 83

84 Test parametrici In alcune applicazioni, può essere necessario scrivere un enorme quantità di test Nelle vecchie versioni di JUnit, la situazione era complicata Per ripetere un test con diversi parametri occorreva scrivere un test case per ogni gruppo di parametri JUnit permette le creazione di test generici che possono essere eseguiti su parametri modificabili Si può quindi creare un unico test case da eseguire più volte, una per ogni gruppo di parametri 84

85 Test parametrici Serie di passi per creare dei test parametrici 1. Creare un normale test, senza parametri 2. Creare un metodo statico di fornitura dati: restituisce unacollection, è annotato 3. Aggiungere campi di classe per i parametri 4. Scrivere un costruttore che riceve dei parametri e inizializza i campi 5. Specificare nella annotazione@runwith che il test case deve essere eseguito con la classe Parameterized 85

86 Esempio di test parametrico Provare una espressione regolare su molti valori Si noti che i valori diphrase ematch non sono public void verifygoodzipcode() throws Exception { Matcher m = this.pattern.matcher(phrase); boolean isvalid = m.matches(); assertequals("pattern did not validate zip code", isvalid, match); 86

87 Fornitura dei parametri Il passo successivo è creare un metodo di fornitura Deve essere static e deve restituire unacollection Deve essere associato all Es. nel metodo si può creare un array multi-dimensionale di Object e convertirlo in una public static Collection regexvalues() { return Arrays.asList(new Object[][] { {"22101", true, {"221x1", false, {" ", true, {" ", false ); 87

88 Creare i campi e il costruttore Ci sono due parametri, di tipostring eboolean, che devono corrispondere a due campi nella classe Poi bsogna creare un costruttore che colleghi i campi ai valori dei parametri private String phrase; private boolean match; public ParametricRegexTest(String phrase, boolean match) { this.phrase = phrase; this.match = match; 88

89 Specificare la classe parametrizzata Infine, bisogna specificare a livello di classe che il test deve essere eseguito con la classeparameterized, usando l public class ParametricRegexTest {... 89

90 Esecuzione di test parametrici Nel test precedente, il metodo verifygoodzipcode viene eseguito 4 volte Una volta per ciascuna coppia riportata dal metodo di produzione datiregexvalues 90