Lo sviluppo software guidato dai test: una esperienza con JUnit

Transcript

1 Lo sviluppo software guidato dai test: una esperienza con JUnit Versione del 13 Gennaio 2004 Vittorio Scarano Dipartimento di Informatica ed Applicazioni Università di Salerno, 84081, Baronissi (SA) Italy. 1 Introduzione Tra le metodologie per lo sviluppo di software, è stata proposta recentemente una disciplina dal nome di Extreme Programming (XP), basata sui valori di semplicità, comunicazione, feedback (testing) e coraggio. L obiettivo principale di XP è quello di organizzare lo sviluppo di software in maniera da escludere la realizzazione di prodotti semilavorati diversi da quelli strettament necessari. In un certo senso, la XP si propone di mantenere il processo di produzione all interno dei due binari di efficacia e della controllabilità. Evitare, quindi, di produrre ponderosa documentazione di analisi e di specifiche formali ed, allo stesso tempo, produrre software con un preciso ambiente di controllo e di feedback, sia dal prodotto software stesso (attraverso fasi di testing) che dal committente e utilizzatore del prodotto. Il dibattito all interno della comunitaà scientifica sulla applicabilità di questa metodologia in tutti i contesti è tuttora aperto; probabilmente l utilizzo di questa metodologia all interno di qualsiasi tipo di progetto ed in qualsiasi situazione rappresenta una esagerazione. La utilità diextreme Programming sembra, però, riconosciuta all interno di progetti di dimensione medio-piccole, con scadenze pressanti e necessità di adeguamento a situazioni estremamente dinamiche. All interno delle prassi consolidate(le cosiddette core practices) proposteda XP, particolarmente interessante è la enfasi sullo Sviluppo guidato dai test, il cosiddetto Test-Driven Development. Infatti, anche tra i commenti più criticia cui è soggetta la XP, si riscontra un convergente giudizio positivo sulla pratica di sottoporre il proprio software in maniera strutturata e continua a test di sviluppo 1. 1 Una altra prassi universalmente giudicata in maniera positiva è la cosiddetta pair programming, cioè la programmazione in coppie di programmatori, cosa che permette (da esperimenti effettuati) la produzione di software di maggiore qualità in tempo minore. 1

2 2 UN ESEMPIO DI APPLICAZIONE 1.1 JUnit Lo sviluppo guidato dai test consiste nella tecnica di sviluppare una nuova funzionalità di un programma attraverso la ripetizione continua di un ciclo di produzione molto breve che consiste di due sole fasi: (1) scrittura di un test che il programma, con la nuova funzionalità, deve poter passare, (2) se il test non viene superato con successo, si modifica il codice nella maniera più semplice possibile per far passare il test. Non si può passare ad un nuovo test se non si sono superati tutti i test precedenti. Basando tutto lo sviluppo di software su questi rapidissimi cicli di produzione, è necessario avere a disposizione uno strumento automatico per la realizzazione di questi test. JUnit, lo strumento che andiamo ora a presentare, ha questo scopo. 1.1 JUnit JUnit è un ambiente per scrivere test scritto da Erich Gamma (autore, con altri, dei Design Patterns) e Kent Beck (autore e guru di Extreme Programming). L ambiente è disponibile anche in altri linguaggi (quali C, C++, SmallTalk, etc.) e supporta il programmatore nella definizione di test, nella loro raccolta in suite di test e nella loro esecuzione. JUnit è Open Source Software, rilasciato sotto la licenza IBM Common Public License (versione 0.5). Ha vinto nel 2002 e nel 2003 il premio JavaWorld Editors Choice Awards (ECA) in qualità di migliore strumento per il Performance Monitoring e il Testing in Java. L obiettivo di JUnit è quello di fornire al programmatore un ambiente che permette di sapere in ogni momento e con poco sforzo se il proprio programma ha superato tutti i test oppure no. Questo permette lo sviluppo rapido del software e la possibilità di rilasciare il programma (release) in ogni momento: infatti ad ogni passo dello sviluppo il programma deve passare con successo il 100% dei test definiti. Questo permette di fondere la fase di testing all interno dello sviluppo, cosa particolarmente utile per progetti di dimensione medio-piccole, dove il codice deve essere pronto ad evolvere guidato dalla dinamicità dei requisiti. Le funzionalità di JUnit rappresentano un ambito familiare dove il programmatore riesce a integrare testing e sviluppo in maniera armonica, permettendo di costruire nuovi test basandosi sui vecchi, di integrare insiemi di test sviluppati da altri programmatori e di valutare con estrema semplicità il risultato dei test. 2 Un esempio di applicazione Presentiamo ora un esempio didattico per illustrare il procedimento di sviluppo guidato dai test. L esempio è scritto in Java ed usa JUnit. E stato sviluppato sotto Eclipse, ma altri ambienti (JBuilder ad esempio) offrono simili funzionalità. In ogni modo, la suite di JUnit permette di svincolarsi completamente da qualsiasi ambiente di sviluppo (non che questo sia necessariamente un bene, attenzione!) e di poter essere eseguita lanciando la JVM da linea di comando. Pag. 2

3 2 UN ESEMPIO DI APPLICAZIONE 2.1 Il nostro obiettivo 2.1 Il nostro obiettivo L obiettivo del nostro esempio è quello di scrivere un metodo media() di una classe Calcolatore che deve, semplicemente, calcolare la media dei valori interi passati come parametro in un vettore e restituirla. Il valore restituito èun intero e, come tale, quindi viene soggetto al troncamento della parte decimale. Insomma la media di 1 e 2 sarà 1. Si tratta, evidentemente, di un metodo che ha valenza esclusivamente esemplificativa eppure, anche attraverso l uso della tecnologia JUnit, riserverà qualche sorpresa anche a programmatori di una certa esperienza. 2.2 La tecnica di JUnit Ricordiamo la filosofia di uso di JUnit: non si deve scrivere una linea di codice senza che sia scritto un test che ne verifichi il corretto funzionamento. Questa posizione (estremista ma, come vedremo, utile) serve a prevenire una pratica sconveniente che viene utilizzata spesso: si sviluppa il software rimandando la fase di testing successivamente. Quando poi, sotto la pressione per la consegna del lavoro, si rende necessario affrettare (oppure eliminare del tutto) qualche fase del lavoro, la prima candidata risulta essere la fase di testing. Questa non è, chiaramente, una scelta intelligente 2 da fare. Forzando il programmatore a scrivere prima un test si ottiene, innanzitutto, a fare sì che il codice sviluppato sia necessariamente testato. Poi, si ottiene anche un effetto virtuoso : il programmatore impara a scrivere nuovo codice creando un test che fallisca sul suo vecchio codice e che, quindi, in un certo senso lo metta in crisi. In questa maniera, il software sviluppato risulta essere particolarmente robusto a malfunzionamenti, in quanto la attitudine (che qualcuno potrebbe definire masochista) del programmatore ha cercato di evidenziare tutte le possibili anomalie durante la fase di sviluppo. Quindi, ricordiamo, la produzione avviene per cicli brevissimi che si compongono delle due fasi seguenti: 1. sviluppo di un test che rappresenta una funzionalità che il nostro codice deve poter offrire; 2. se il codice non viene passato, si propone la più semplice soluzione che possa risolvere il problema. Un commento merita la enfasi sulla semplicità della soluzione da proporre. A volte, sembra che questo suggerimento non abbia molto senso: in un certo senso la soluzione può anche cercare di prevenire problemi futuri. Questo, però, rappresenta esattamente il contrario della filosofia dello sviluppo guidato dai test che richiede che ogni parte di codice sia testata. Quindi, scrivere soluzioni complesse significherebbe introdurre codice cui non corrisponde un test da superare e quindi, codice non affidabile. 2 E stato scritto che questo equivale a spegnere la luce proprio quando la notte si fa più buia. Pag. 3

4 2 UN ESEMPIO DI APPLICAZIONE 2.3 Il primo passo 2.3 Il primo passo Iniziamo, secondo il puro stile JUnit, con lo scrivere il nostro codice iniziando dal test. Quindi, dovendo scrivere un metodo che calcoli la media di un vettore di interi, si deve partire dal primo test. Creiamo, quindi una test unit (come classe JUnit) che faccia un test iniziale. La prima stesura del file (che chiameremo CalcolatoreTest.java) sarà seguente: 1 import junit.framework.testcase; 2 public class CalcolatoreTest extends TestCase { 3 Calcolatore c; 4 public void setup(){ 5 c = new Calcolatore(); 6 } 7 public void testiniziale(){ 8 int[] valori = new int[]{0}; 9 assertequals(0, c.media(valori)); 10 } 11 } Come si può notare alla linea 2, la classe CalcolatoreTest eredita dalla classe junit.framework.testcase.testcase. Dopo avere dichiarato come campo della classe una variabile c oggetto istanza della classe Calcolatore (linea 3), definiamo, innanzitutto, un metodo setup() (linee 4-6) che ha lo scopo di approntare gli oggetti che servono per ogni test. Ricordiamo che il metodo setup() viene chiamato prima della esecuzione di ognimetododiquestaclasseilcuinome inizia per test. In questo esempio non abbiamo la necessità di utilizzare il metodo teardown() che viene chiamato alla fine della esecuzione di ogni singolo test. Fedeli alla filosofia del Test-Driven Development, cerchiamo di scrivere il primo test quando ancora non abbiamo scritto neanche una riga della classe Calcolatore. Lacosapuò sembrare paradossale, ma una volta abituati e, specialmente, una volta osservato i vantaggi che questa tecnica porta, diventerà una maniera molto naturale di procedere. Per prima cosa vogliamo che il nostro metodo calcoli correttamente la media Test # 1. La media di 0 è 0. di 0. Quindi, il test che vogliamo scrivere, che chiamiamo, opportunamente, testiniziale() è contenuto alle linee La prima cosa che vogliamo controllare è che questo metodo calcoli correttamente la media di un solo valore, 0, che viene inserito in un vettore di interi chiamato valori dimensionato ad un solo elemento. Questo viene effettuato controllando (linea 9) con assertequals che il risultato restituito dal metodo media() passando valori come parametro sia uguale a 0. A questo punto possiamo passare ad effettuare il primo di una lunga se- rie di test a cui sottoporremo la nostra classe Calcolatore. In effetti, questo primo test risulta davvero estremamente sfortunato: non riusciamo neanche a Pag. 4

5 2 UN ESEMPIO DI APPLICAZIONE 2.3 Il primo passo compilare la classe CalcolatoreTest per il semplicissimo motivo che la classe Calcolatore (cioè laclassecheè da testare) non esiste ancora! Quindi, dobbiamo, come prima cosa creare questa classe con il metodo richiesto media(). Ecco il risultato: 1 public class Calcolatore { 2 public int media(int[] valori) { 3 return 0; 4 } 5 } In effetti, avere scritto questa versione (assolutamente minimalista) della classe Calcolatore, risponde alla precisa indicazione di semplicità che viene dettata dalle prassi della cosiddetta Extreme Programming. In sintesi,il principio richiede al programmatore di scrivere la soluzione più semplice per poter far passare il test. Non si richiede (anzi viene sconsigliato) il cercare di progettare ipotizzando i test futuri a cui il nostro oggetto verrà sottoposto. In effetti, dopo aver scritto queste poche righe di codice il nostro test testiniziale() viene passato: il nostro metodo media() calcola la media di 0. Quando abbiamo finito di festeggiare, possiamo passare al nostro prossimo test. Diciamo che vorremmo che il nostro metodo calcoli correttamente la Test # 2. La media di 1 è 1, media di 0 ma anche la media di 1, 2,..., diciamo almeno fino a 9. Quindi possiamo passare a scrivere il prossimo test che chiamiamo testognivalore(). Ricordiamo che ad ogni passo verranno rieseguiti tutti i test contenuti nel TestCase CalcolatoreTest, quindi alla prossima esecuzione verranno eseguiti sia testiniziale() che testognivalore(), e così via per ogni test che aggiungeremo. Ecco il codice di testognivalore(): quella di 2 è 2, etc. fino a 9. 1 public void testognivalore() { 2 int[] valori = new int[1]; 3 String message; 4 for (int i=0; i<10; i++) 5 { 6 valori[0]=i; 7 message = "Media di "+i; 8 assertequals(message,i, c.media(valori)); 9 } 10 } Come possiamo notare, il test controlla che il valore sia corretto alla linea 8. Lanciamo questo test e, non senza stupore, riscontriamo che il test fallisce quando proviamo a calcolare la media di 1. Pag. 5

6 2 UN ESEMPIO DI APPLICAZIONE 2.3 Il primo passo Bene. Proviamo a fare passare questo test. Ricordiamo l obbligo di mantenere la semplicità nelle modifiche. Quindi la nostra modifica consiste nello scrivere il metodo media() in modo che restituisca come media il primo valore del vettore così: 2 return valori[0]; 3 } Lanciamo il test e notiamo che viene superato. Proviamo a controllare se il nostro metodo calcola la media correttamente Test # 2. La media di -1 è - anche se passiamo un valore negativo. Quindi quello che vogliamo controllare è effettuato dal questo metodo che aggiungiamo a CalcolatoreTest. 1, quella di -2 è -2, etc. fino a public void testvalorenegativo() { 2 int[] valori = new int[1]; 3 String message; 4 for (int i=-9; i<0; i++) 5 { 6 valori[0]=i; 7 message = "Media di "+i; 8 assertequals(message,i, c.media(valori)); 9 } 10 } Eseguiamo il test ed otteniamo che va tutto bene. Questo in generale, non è un bene... Effettivamente, il test che abbiamo scritto sembra inutile (in questo momento) e dobbiamo passare ad un passo successivo, insomma abbiamo preso coraggio ed è ora di passare oltre. Adesso, coraggiosamente cerchiamo di controllare se il metodo media() Test # 3. La media di 1 e 1 è calcola la media correttamente quando passiamo due valori uguali. Questo controllo viene effettuato da questo test: 1, quella di 2 e 2 è 2, etc. fino a 9 e 9. 1 public void testognicoppiaconstessovalore() { 2 int[] valori = new int[2]; 3 String message; 4 for (int i=0; i<10; i++) 5 { 6 valori[0]=i; 7 valori[1]=i; 8 message = "Media di "+i+" e "+i; 9 assertequals(message,i, c.media(valori)); Pag. 6

7 2 UN ESEMPIO DI APPLICAZIONE 2.3 Il primo passo 10 } 11 } Effettuiamo il test e (ancora una volta!) otteniamo che il test funziona. Dobbiamo essere ancora più coraggiosi, proviamo a fare la media di coppie Test # 4. La media tra 7 e 9 è 8. di valori diversi! Quindi scriviamo in CalcolatoreTest il metodo seguente che controlla se media() calcola correttamente la media tra 7 e 9: 1 public void testduevalori(){ 2 int[] valori = new int[]{7,9}; 3 assertequals(8, c.media(valori)); 4 } Lanciamo il test e, finalmente, notiamo che il nostro test fallisce. Finalmente possiamo mettere mano al codice del nostro metodo. La soluzione sembra semplice, no? In effetti, basta restituire il valore della media calcolata sui due interi, semplice. E quello che facciamo: 2 return (valori[0]+ valori[1])/2; 3 } Fatto? Proviamo ad eseguire il test e, con sorpresa, notiamo che non va a buon fine! Infatti questa volta il test che fallisce è uno dei precedenti: la modifica che abbiamo fatto, mentre ha fatto superare l ultimo test, ha però resononpiùcor- retto il testiniziale lanciando la eccezione ArrayIndexOutOfBoundsException. Infatti, basta notare che, quando passiamo un vettore di un solo elemento il risultato dipende solo dal primo, mentre nel caso in cui passiamo due valori (diversi) il risultato dipende da entrambi. E quindi è importante utilizzare all interno del codice la lunghezza del vettore passato come parametro a media(). Unpoco di riflessione ci convince che dobbiamo necessariamente calcolare la media in funzione del numero di elementi passati nel vettore, scrivendo quindi il codice seguente: 2 int sommavalori=0; 3 for (int i=0; i< valori.length ; i++) { 4 sommavalori += valori[i]; 5 } 6 return sommavalori/valori.length; 7 } Ed adesso il nostro metodo funziona correttamente su ciascuno dei test che abbiamo sviluppato. Pag. 7

8 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice Giusto per essere sicuri, facciamo in modo di controllare che la media di Test # 5. La media di tutte le tutte le possibili combinazioni di valori tra 0 e 9 sia corretta. Scriviamo quindi questo metodo: coppie i e j, tra 0 e 9è corretta. 1 public void testognicoppia() { 2 int[] valori = new int[2]; 3 String message; 4 for (int i=0; i<10; i++) 5 for (int j=0; j<10; j++) { 6 valori[0]=i; 7 valori[1]=j; 8 message = "Media di "+i+" e "+j; 9 assertequals(message,(i+j)/2, c.media(valori)); 10 } 11 } Funziona! In effetti, adesso possiamo eseguire tutti i nostri test ed ottenere finalmente che tutti funzionano. Questa stesura del metodo della media rappresenta quella che probabilmente qualsiasi programmatore avrebbe realizzato in partenza. La cosa, adesso, si fa interessante. Come possiamo cercare di costruire un test che questo metodo non riesce a superare? 2.4 Miglioriamo il codice E venuto il momento di testare cosa succede se forniamo al metodo dei dati in maniera non corretta. Ad esempio, un primo controllo che si dovrebbe fare è Test # 6. Con vettore null, quello di controllare che il metodo media() quando viene passata una variabile con valore null restituisca una eccezione IllegalArgumentException. Come al solito, questo viene effettuato scrivendo prima il test, facendolo fallire e poi modificando il codice per far passare il test (e tutti i precedenti). quindi, questo metodo: Creiamo, lancia una eccezione. 1 public void testarraynull() { 2 int[] valori = null ; 3 try { 4 int media = c.media(valori); 5 fail ("Permette un array null!"); 6 } catch (IllegalArgumentException e) { 7 // non colta 8 } 9 } E da notare che alla linea 5 non si fa altro che chiedere al metodo di calcolare la media di un vettore null. Non si controlla il risultato: piuttosto, se la chiamata a media() non genera una eccezione IllegalArgumentException(che Pag. 8

9 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice viene colta dalla catch della linea 6) allora lanciamo una eccezione con il metodo fail(). Eseguiamo il test e vediamo che effettivamente questo fallisce. In effetti, fallisce perché viene generata una eccezione NullPointerException nella riga 3 della ultima stesura del metodo media(), quando si cerca di accedere al campo length di un riferimento null. Come possiamo modificare il codice di media()? Inserendo un controllo (a inizio metodo) che il parametro passato non sia nullo. Ecco fatto: 2 int sommavalori=0; 3 if (valori == null) 4 throw new IllegalArgumentException(); 5 for (int i=0; i< valori.length ; i++) { 6 sommavalori += valori[i]; 7 } 8 return sommavalori/valori.length; 9 } Tutto a posto! Adesso lanciamo i test e vanno a buon fine tutti. metodo media() un vettore di interi che ha lunghezza 0, questo potrebbe creare dei problemi. Vediamo: Continuiamo a cercare di mettere in crisi il metodo media(). Una situazione Test # 7. Con vettore di lun- abbastanza intricata non è stata ancora controllata. Infatti, se passiamo al ghezza 0, lancia una eccezione. 1 public void testarrayvuoto () { 2 int[] valori = new int[0]; 3 try { 4 int media = c.media(valori); 5 fail ("Permette un array di zero elementi!"); 6 } catch (IllegalArgumentException e) { 7 // non colta 8 } Effettivamente ci siamo riusciti! Adesso il nostro metodo media() dà un errore dovuto alla divisione per zero che si effettua alla fine nella linea 8, essendo valori.length pari a 0. Modifichiamo il codice di media() per risolvere questo problema. Supponiamo, ora, che il programmatore compia un errore dovuto alla distrazione cioè che inserisca nella funzione media un controllo che nella condizione dell if contenga l AND logico delle condizioni (valori == null) e (valori.length == 0) invece che l OR logico, come sarebbe corretto. Un errore banale, ma che può capitare. Quindi modifichiamo il codice come segue: Pag. 9

10 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice 2 int sommavalori=0; 3 if (valori == null && valori.length==0) 4 throw new IllegalArgumentException(); 5 for (int i=0; i< valori.length ; i++) { 6 sommavalori += valori[i]; 7 } 8 return sommavalori/valori.length; 9 } A questo punto, il programmatore (che ha compiuto l errore) potrebbe ritenere di aver risolto il problema e passare a fasi successive (magari anche ad altro codice). Invece, la metodologia dello sviluppo guidato dai test, obbliga a controllare che ogni linea di codice superi il 100% dei test elaborati. Quindi, viene lanciato il test che, contrariamente alle aspettative del programmatore, non viene passato. Quindi il programmatore può scoprire l errore e scrive correttamente il codice come segue: 2 int sommavalori=0; 3 if (valori == null valori.length==0) 4 throw new IllegalArgumentException(); 5 for (int i=0; i< valori.length ; i++) { 6 sommavalori += valori[i]; 7 } 8 return sommavalori/valori.length; 9 } Si può controllare il programma e verificare che ora tutti i test (compreso l ultimo) vengono passati con successo. Facciamo un attimo di pausa e commentiamo sulla attitudine di cercare di mettere in crisi il proprio codice per scoprirne debolezze e correggerle. L ultimo test rappresenta un classico esempio di come questa maniera di programmare produca codice più robusto ed affidabile. Un metodo media() come quello che abbiamo elaborato finora gestisce anche casi limite (come, ad esempio, il vettore non nullo ma di zero elementi) che normalmente non ci saremmo posti come problema (da programmatore) se il gioco che stiamo giocando non comportasse l obbligo di cercare di far fallire il nostro stesso programma per correggerne gli errori Non solo, proprio l ultimo esempio ha dimostrato come la abitudine a dover passare un test per ogni linea di codice scritta permette di far scoprire al programmatore distratto alcuni errori che magari sarebbero passati inosservati 3 come quello dell utilizzo di un AND logico al posto di un OR logico. 3 La legge di Murphy garantisce che gli errori si sarebbero evidenziati nella peggiore del- Pag. 10

11 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice Adesso, immaginiamo un altro tipo di casi limite, ad esempio, quando i valori Test # 8. passati all interno del vettore valori risultano essere molto grandi. Quindi, controlliamo che il metodo media() calcoli correttamente la media di un singolo valore che è pari al massimo valore memorizzabile in un intero, che è definito come una costante nella classe wrapper per gli interi: Integer.MAX VALUE. Scriviamo quindi il metodo seguente: 1 public void testmaxvalueintero() { 2 int[] valori = new int[1]; 3 String message; 4 valori[0]=integer.max_value; 5 message = "Media di "+valori[0]; 6 assertequals(message,integer.max_value, c.media(valori)); 7 } Proviamo ad eseguirlo... e funziona. Dobbiamo trovare qualche cosa di meglio. La media di MAX VALUE è MAX VALUE. generata un eccezione ArithmeticException: 1 public void testduemaxvalueintero() { 2 int[] valori = new int[2]; 3 String message; 4 try { 5 valori[0]=integer.max_value; 6 valori[1]=integer.max_value; 7 message = "Media di "+valori[0]+" e "+valori[1]; 8 assertequals(message,integer.max_value, c.media(valori)); 9 fail ("Non riconosce l overflow!"); 10 } catch (ArithmeticException e) { 11 // non colta 12 } 13 } Proviamo a scrivere un test simile ma questa volta che fallisca. Ovviamente, il problema si presenterà se andiamo a calcolare la media di due MAX VALUE. Scriviamo quindi il seguente metodo, prevedendo che in caso di overflow venga Test # 9. La media di 2 valori MAX VALUE è MAX VALUE. Evviva! Il test fallisce! In effetti, si deve trattare il problema dell overflow: stiamo sommando dei valori interi e potremmo oltrepassare la capacità dime- morizzazione di un intero in Java. Due sono i passi che dobbiamo fare: (1) Come si fa a controllare se abbiamo generato un overflow? (2) cosa dobbiamo fare in questo caso? La risposta alla seconda domanda è semplice: si deve lanciare una eccezione di tipo ArithmeticException. La risposta alla prima domanda invece si nasconde nei meandri dei ricordi degli studi effettuati al primo anno del corso di le situazioni in maniera, cioé, da recare simultaneamente il massimo danno al client, allo sviluppatore ed al manager del progetto. Pag. 11

12 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice Laurea in Informatica. Infatti, durante il corso di Architettura, si impara come controllare l overflow di operazioni in complemento a due: quando si sommano due positivi il risultato deve essere positivo, altrimenti vuol dire che abbiamo generato un overflow. A questo punto la maniera per modificare il metodo media() è il seguente: 2 int sommavalori=0; 3 int appoggiosomma; 4 if (valori == null valori.length == 0) 5 throw new IllegalArgumentException(); 6 for (int i=0; i< valori.length ; i++) { 7 appoggiosomma = sommavalori; 8 sommavalori += valori[i]; 9 if (appoggiosomma > 0 && valori[i]> 0 && sommavalori < 0) 10 throw new ArithmeticException(); 11 } 12 return sommavalori/valori.length; 13 } Quello che è stato fatto è semplicemente l inserimento di una nuova variabile intera appoggiosomma che mantiene (linea 7) il valore della variabile sommavalori prima che questa venga modificata (nella linea 8). A questo punto si può controllare se la somma del vecchio valore e del valore che stiamo sommando (valori[i]) ha generato un valore negativo (linea 9). In questo caso lanciamo una eccezione (linea 10). Controlliamo se funziona tutto. Lanciamo il test ed otteniamo che non ci sono errori. Ok, bene. Abbiamo capito in che direzione andare. Dovremmo testare cosa succede anche con MIN VALUE. In questo momento dobbiamo ricordarci di applicare (alla lettera) i dettami del Test-driven Development: si deve modificare il programma nella maniera più semplice per poter passare il test che aveva fallito in precedenza. Quindi, prima di fare qualsiasi modifica che permetta di gestire a vedere se riusciamo a calcolare correttamente la media di due valori negativi molto piccoli (MIN VALUE) con questo metodo: overflow negativi dobbiamo scrivere un test e farlo fallire. Quindi, proviamo Test # 10. La media di 2 valori MIN VALUE è MIN VALUE. 1 public void testdueminvalueintero() { 2 int[] valori = new int[2]; 3 String message; 4 try { 5 valori[0]=integer.min_value; 6 valori[1]=integer.min_value; 7 message = "Media di "+valori[0]+" e "+valori[1]; 8 assertequals(message,integer.min_value/2, c.media(valori)); Pag. 12

13 2 UN ESEMPIO DI APPLICAZIONE 2.4 Miglioriamo il codice 9 fail ("Non riconosce l overflow negativo!"); 10 } catch (ArithmeticException e) { 11 // non colta 12 } 13 } Evviva! Non funziona. Adesso possiamo modificare il programma. E la cosa sembra facile: abbiamo appena tratta il caso dell overflow positivo, basta invertire le condizioni e tratteremo l overflow negativo. Vediamo cosa otteniamo. 2 int sommavalori=0; 3 int appoggiosomma; 4 if (valori == null valori.length == 0) 5 throw new IllegalArgumentException(); 6 for (int i=0; i< valori.length ; i++) { 7 appoggiosomma = sommavalori; 8 sommavalori += valori[i]; 9 if (appoggiosomma > 0 && valori[i]> 0 && sommavalori < 0) 10 throw new ArithmeticException(); 11 if (appoggiosomma < 0 && valori[i]< 0 && sommavalori > 0) 12 throw new ArithmeticException(); 13 } 14 return sommavalori/valori.length; 15 } Bene, sembra fatta. Eseguiamo il test... e non funziona! Perché? Abbiamo semplicemente invertito le condizioni per l overflow positivo? Perché nonva? Un pochino di osservazione vi farà notare che le condizioni di overflow non sono speculari: mentre basta controllare che la somma di due positivi dia un negativo per controllare l overflow positivo, per controllare l overflow negativo si deve controllare anche che il risultato non sia zero! Infatti la somma di due valori MIN VALUE dà come risultato proprio zero! Quindi dobbiamo modificare la linea 11 in modo da controllare anche se il risultato della somma di due negativi dà zero, come segue: 2 int sommavalori=0; 3 int appoggiosomma; 4 if (valori == null valori.length == 0) 5 throw new IllegalArgumentException(); 6 for (int i=0; i< valori.length ; i++) { 7 appoggiosomma = sommavalori; 8 sommavalori += valori[i]; 9 if (appoggiosomma > 0 && valori[i]> 0 && sommavalori < 0) Pag. 13

14 3 CONCLUSIONI 10 throw new ArithmeticException(); 11 if (appoggiosomma < 0 && valori[i]< 0 && sommavalori >= 0) 12 throw new ArithmeticException(); 13 } 14 return sommavalori/valori.length; 15 } Bene, adesso funziona tutto. 3 Conclusioni 3.1 Alcuni commenti La tecnologia relativa a JUnit rappresenta uno strumento molto utile per il supporto al programmatore. Una volta abituatisi allo stile di programmazione (che richiede di partire, in maniera apparentemente irrazionale, dalla scrittura di test per arrivare (solo successivamente) alla scrittura del codice) l aiuto che viene fornito al programmatore risulta notevole. Con questo semplice esempio abbiamo voluto enfatizzare alcuni degli aspetti positivi della tecnica programmazione guidata dai test. In particolare, ritengo opportuno sottolineare come alcune situazioni potenzialmente pericolose sono state evitate proprio con la enfasi sulla attività di test che deve precedere quella di codifica. Ad esempio, possiamo citare il passo del Test n. 10 che verificava la corretta segnalazione di overflow in caso di somma di due valori MIN VALUE. La asimmetria nella condizione di test per l overflow positivo e quella per l overflow negativa sarebbe potuta probabilmente sfuggire anche a programmatori esperti. L obbligo di fornire prima un test specifico, che deve essere passato con successo, ha forzato il programmatore a scrivere un test apparentemente banale e inutile (vale a dire, che doveva sicuramente essere passato) che ha rivelato invece un problema nel codice la cui soluzione ha permesso di creare del codice di maggiore qualità (robusto ed affidabile). Una situazione di errore diversa, ma egualmente pericolosa, si è verificata nel il Test n. 7 che ha permesso di scoprire immediatamente una distrazione del programmatore. Riconoscere immediatamente un errore così banale ha dei notevoli vantaggi pratici ed economici: in quel momento, e trattando quei programmi, il programmatore ha immediatamente riconosciuto e potuto correggere l errore. Immaginate, invece, il tempo che avrebbe impiegato se, magari dopo due mesi, un tester (o peggio, il cliente!) avesse chiamato per dire che A uncertopunto viene generata una eccezione... e non funziona più nulla!. Il programmatore potrebbe impiegare giorni interi per trovare questo semplice errore. Un altro aspetto particolarmente interessante è il fatto che il nostro progetto software compie solamente passi avanti in quanto ad ogni fase di test effettuiamo tutti i test contenuti nella test unit. Questo ha permesso di evidenziare errori Pag. 14

15 RIFERIMENTI BIBLIOGRAFICI 3.2 Note bibliografiche che possono essere stati inseriti successivamente, modificando parti del codice apparentemente non correlate. Dopo aver terminato la descrizione delle meraviglie di questo framework, una parola deve essere spesa per avvertire di alcune limitazioni della tecnologia JUnit. Innanzitutto, si deve assolutamente evitare di considerare codice prodotto da questa tecnica come error free. Diciamo che la tecnologia JUnit facilita la vita di chi deve scrivere codice attraverso una attività ditestcontinuoma che non forza nessuno a scrivere dei test significativi. Insomma, JUnit è uno strumento efficace, ma semplicemente il fatto di usarlo non garantisce la qualità del nostro software: ci vuole anche molta inventiva, esperienza e capacità per usarlo al meglio. Poi, si dovrebbe tenere presente le limitazioni di uso di JUnit all interno di applicazioni. Ad esempio, mentre sembra immediato l uso per le parti della applicazione che compongono la business logic, èpiù difficile immaginarne l uso per la componente di visualizzazione. Anche se qualche sistema di testing automatico per interfacce su palmari esiste, un sistema così completo come JUnit per testare la qualità diunainterfacciasembracomplicatodaottenere. 3.2 Note bibliografiche Molte informazioni su Extreme Programming possono essere trovate su alcuni siti dedicati a questa metodologia di programmazione [1, 2]. Materiale ed informazioni su JUnit si trovano, invece, sul sito ufficiale dedicato a JUnit [3], e nella documentazione che si trova nel package che viene scaricato (nella directory doc). Infine, interessante è il materiale contenuto nella JUnit Frequently Asked Questions [4]. L esempio di uso della media è stato ispirato (almeno per la parte iniziale) da un (più semplice) esempio mostrato in Riferimenti bibliografici [1] [2] [3] JUnit Official Home Page [4] JUnit Frequently Asked Questions Pag. 15