Errori a tempo di compilazione (1) Verifica del Comportamento degli Oggetti. Errori a tempo di compilazione (3) Errori a tempo di compilazione (2)

Transcript

1 Errori a tempo di compilazione (1) 2 Verifica del Comportamento degli Oggetti Classi di Errori Il testing Test driver Strategie di testing Selezione dei casi di test Errori che possono occorrere durante la traduzione (compilation-time errors) Errori sintattici: Errori nella grammatica o struttura dei costrutti Java Mancare un punto e virgola o una virgola, es: x = 5 f(a b) Errato uso di parentesi, es: (3 + 5 Altre forme di espressioni errate, es: 3 + % 5 Errori a tempo di compilazione (2) Errori semantici: errori nel significato del costrutto Uso di variabili non dichiarate Uso di variabili non inizializzate, es: int i; i++; Assegnazione di una stringa ad un intero String s = Hello ; int i; i = s; 3 Errori a tempo di compilazione (3) Molti degli errori semantici sono errori di tipo uso di una variabile in maniera inconsistente con il suo tipo Uso di un oggetto in un espressione aritmetica Invocazione di un messaggio su un oggetto che non possiede tale metodo Invio di un messaggio ad un tipo di dato primitivo Assegnazione di un double ad un int(possibile perdita di dati) 4 Errori a tempo di esecuzione (1) Errori che possono occorrere durante l esecuzione del codice Java (run-time errors) Cosa accade nel codice seguente se alla variabile x viene assegnato il valore 0? int w, x; x = Integer.parseInt( ); w = 10/x; Si avrebbe il seguente messaggio di errore: java.lang.arithmeticexception: divide by zero at. 5 Errori a tempo di esecuzione (2) Sono più difficili da correggere, perché non sempre è facile determinarne la causa int w, x, y, z; x = Integer.parseInt( ); y = Integer.parseInt( ); z = Integer.parseInt( ); // Code which manipulates x.y, and z using ifstatements w = 10 / ((x - y) * z); Si supponga una divisione per zero nell ultima espressione Anche quando si riesca a scoprire la causa dell errore, potrebbe essere non facile correggerlo 6

2 7 8 Errori a tempo di esecuzione (3) Debugging: la correzione di un run-time error I run-time errors sono chiamati bugs Il debugging è una delle attività che consumano più tempo nei processi di sviluppo software Cercare i bugs in un programma richiede una fase di testing Errori logici Anche gli errori logici si rivelano in fase di esecuzione, ma non producono un messaggio di errore Piuttosto, in certi casi il nostro risultato può essere sbagliato, o il programma può non funzionare come dovrebbe Tali errori possono essere solo determinati mediante il testing 9 10 Testing Una classe va verificata quando viene scritta, non quando viene usata: Il testing è una parte del processo di sviluppo, non qualche cosa da fare solo quando occorre qualche problema Quando si usa una classe la si vuole usare con fiducia. Questo è possibile solo se la classe è già stata verificata Il testing si effettua meglio quando il codice è ancora fresco nella mente, ossia la prima volta che si sviluppa una classe Test drivers (1) Problema: come verificare una classe di utilità (ossia una senza il metodo main e il cui scopo è quello di essere usata in programmi più grandi)? Risposta: Si scrive un test driver per la classe Un test driver è un metodo il cui solo scopo è quello di eseguire il testing della classe Test drivers (2) - Un esempio class Employee { Employee e = new Employee("Gerald Weiss", 25); int hours = 36; System.out.print("Employee name: "); System.out.println(e.getName()); System.out.print("Rate: "); System.out.println(e.rate); System.out.print("Hours: "); System.out.println(hours); System.out.print("Pay: "); System.out.println(e.calcPay(hours));... // resto della classe 11 Test drivers (3) La responsabilità del driver è quella di invocare i vari metodi della classe in modo tale che il comportamento possa essere testato Il test driver dovrebbe essere statico perché esso non è invocato con alcun ricevente Inserendo il test driver nella classe, la classe porta con sé il suo test 12

3 13 14 Test drivers (4) - Vantaggi Testing automatico (1) Un test driver aiuta ad automatizzare il testing della classe Se capita un problema e viene cambiata una qualsiasi parte della classe, la classe deve essere completamente ri-testata Ciò è noto come regression testing I test drivers aiutano in quanto mantengono traccia dei tests che sono stati eseguiti originariamente Il test driver dovrebbe essere in grado di determinare se il risultato è corretto o meno (evitando di farlo a mano) Ciò è utile per una serie di motivi: Il calcolo potrebbe essere complesso Potrebbe essere necessaria l esecuzione di molti test Gli umani si annoiano a leggere i risultati dei test e commettono errori Testing Automatico (2) Primo approccio Stampare la risposta corretta (precalcolata) insieme alla risposta calcolata dalla classe 15 Testing Automatico (3) Un approccio migliore Confrontare la risposta corretta e quella calcolata, inviando un messaggio di errore in caso di discrepanza 16 Employee e = new Employee("Gerald Weiss", 25); int hours = 36; int correctanswer = 900; // I used my calculator to get this value System.out.print("Employee name: " + e.getname()); System.out.print("Rate: " + e.getrate()); System.out.print("Hours: " + hours); System.out.print("Pay (computed): "); System.out.println(e.calcPay (hours)); System.out.print("Pay (correct): "); System.out.println(correctAnswer);... // come prima, e in più il seguente confronto... if (computedpay!= correctanswer) { System.out.print("*** Error + "computed pay does not " + "match correct answer of " + correctanswer + " Test failed!"); else System.out.println("Successful!"); Testing Automatico (4) Aggiungiamo un metodo di verifica Sebbene utile, il precedente confronto con stampa di un messaggio di errore è talvolta tedioso Sarebbe meglio avere un metodo che effettua il confronto e stampa la conseguente diagnostica Creiamo un metodo verify che faccia questo Tale metodo è static, perché non ha un ricevente prende in ingresso il (risultato del) confronto e come secondo parametro l eventuale messaggio (di errore) da stampare Inseriamo tale metodo in una classe TestHelper 17 Testing automatico (5) Il metodo di verifica class TestHelper { static void verify(boolean testcondition, String message) { if (!testcondition) { System.out.print("*** Error - test failure: "); System.out.println(message); Thread.dumpStack(); L invocazione di Thread.dumpStack produce una traccia di dove si trovava il programma quando dumpstack è stato chiamato 18

4 Testing automatico (6) Esempio di uso del metodo verify 19 Un primo approccio al testing 20 Un semplice esempio di chiamata al metodo La prima e basilare legge del testing: intx = 5, y = 0; TestHelper.verify(x == y, Just a test ); Se non è stato verificato, non funziona!!! e il suo output *** Error - test failure: Just a test java.lang.exception: Stack trace at java.lang.thread.dumpstack(thread.java:892) at TestHelper.verify(TestHelper.java:11) at Test.main(Test.java:7) Devono essere verificati tutti i comportamenti Tutti i metodi public devono essere testati dal test driver Anche i metodi privati devono essere testati Lo si può fare se il test driver fa parte della classe Cercare un ordine logico Esecuzione di tutte le istruzioni Verificare ogni metodo di stampa quanto prima Verificare i costruttori prima Se gli oggetti non sono stati creati propriamente, niente lavorerà correttamente I metodi più semplici e primitivi dovrebbero essere verificati prima I metodi più complessi, che dipendono da altri metodi nella classe, dovrebbero essere verificati dopo aver verificato i metodi da cui dipendono (strategia bottom-up) All-statement testing: ogni istruzione dovrebbe essere eseguita almeno una volta, es.: if (hours <= 40) pay = hours * rate; else pay = hours*rate + (hours-40)*(rate/2); Se non verifichiamo almeno due casi, hours <= 40 e hours > 40, uno dei due assegnamenti a pay Non è stato eseguito e quindi non è stato verificato e quindi NON FUNZIONA!!! Esecuzione di tutti i cammini Flusso di controllo All-path testing: è un alternativa alla strategia precedente In questa strategia, non solo ogni istruzione, ma ogni diverso cammino nel codice deve essere verificato da notare che all-path testing all-statement testing Per vedere la differenza, si consideri il seguente codice if(condition1) // true 1 else // false 1 if(condition2) // true 2 else // false 2 Il codice dell esempio precedente può essere rappresentato in questo modo: condition 1 false 1 true 1 condition 2 false 2 true 2

5 25 26 Esecuzione di tutte le istruzioni L esecuzione di tutte le istruzioni può essere ottenuta nel modo seguente: Test 1: condition 1 true; condition 2 true Vengono eseguiti true 1 e true 2 Test 2: condition 1 false; condition 2 false Vengono eseguiti false 1 e false 2 Esecuzione di tutti i cammini Invece, l esecuzione di tutti i cammini richiede: Test 1: condition 1 true; condition 2 true cammino true 1, true 2 Test 2: condition 1 false; condition 2 false cammino false 1, false 2 Test 3: condition 1 true; condition 2 false cammino true 1, false 2 Test 4: condition 1 false; condition 2 true cammino false 1, true Esecuzione di tutti i rami In generale, l esecuzione di tutti i cammini è molto costosa e spesso può essere impossibile da realizzare (infesible paths) D altra parte l esecuzione di tutte le istruzioni potrebbe non essere sufficiente Una via di mezzo è data dall esecuzione di tutti i rami (all-branchs testing) Verificare sia il caso true che false di ogni decisione In generale all-paths all-branchs all-statements Verificare casi speciali (1) Valori di frontiera (boundary values) se una condizione verifica un intervallo, i valori immediatamente dentro e fuori l intervallo dovrebbero essere verificati Per esempio, nel test: if(hours <= 40) pay = hours * rate; else pay = hours * rate + (hours 40) * (rate / 2); Non basta verificare i valori 20 e 50 per hours, ma bisogna verificare i valori 39, 40 e 41 Immaginare cosa succede se per errore si fosse scritto: if(hours < 40) Verificare casi speciali (2) Per gli interi, i valori 0 e < 0 spesso causano problemi e dovrebbero essere verificati Per le stringhe, la stringa vuota è un caso speciale e dovrebbe essere verificata Per le variabili di reference in generale, dovrebbe essere preso in considerazione il valore null Note finali Lo scopo del testing è verificare il comportamento Meglio svolgere una verifica in modo lento e completo che una estremamente veloce ma superficiale Tecniche di debugging Utili i debugger, ma non sempre disponibili Un metodo universale: inserire stampe di valori in determinati punti del programma (ad esempio, prima o dopo la verifica di una condizione da ispezionare, per individuare il cammino eseguito)