Testing e debugging. Validazione (1) Il problema: Assicurarsi se un programma funziona come intendiamo e scoprire perché non lo fa, se questo è il caso.

Presentazione sul tema: "Testing e debugging. Validazione (1) Il problema: Assicurarsi se un programma funziona come intendiamo e scoprire perché non lo fa, se questo è il caso."— Transcript della presentazione:

1 Testing e debugging

2 Validazione (1) Il problema: Assicurarsi se un programma funziona come intendiamo e scoprire perché non lo fa, se questo è il caso. La parola validazione si riferisce a un processo fatto per accrescere la nostra fiducia che un programma si comporterà come intendiamo. La validazione è fatta di solito con una combinazione di testing e di ragionamento per convincerci che il programma è corretto. Con debugging ci si riferisce al processo fatto per capire perché un programma non funziona. Con defensive programming ci si riferisce alla pratica di scrivere programmi in un modo destinato a facilitare i processi di validazione e di debugging.

3 Validazione (2) Quale è lo scopo del processo di validazione? Il risultato piú desiderabile sarebbe la garanzia assoluta che tutti gli utenti del programma saranno sempre soddisfatti del suo comportamento. Questo non è ottenibile. Il miglior risultato che possiamo sperare di raggiungere è che un programma soddisfi la sua specifica. Ci sono due strade per la validazione. Possiamo cercare di argomentare che il programma funziona per tutti i possibili input. Questa attività richiede un ragionamento sul testo del programma ed è chiamata verifica. La verifica formale è troppo pesante senza l’aiuto di una macchina e gli strumenti a disposizione oggi sono insoddisfacenti. Perciò la maggior parte della verifica è ancora fatta in modo piuttosto informale ed è un processo difficile.

4 Validazione (3) L’alternativa alla verifica è il testing. Possiamo facilmente convincerci che un programma funziona su un insieme di input eseguendolo su ciascun membro dell’insieme e controllando i risultati. Se l’insieme di input possibili è piccolo un testing esaustivo è possibile. Tuttavia per la maggior parte dei programmi l’insieme dei casi possibili è cosí grande che un testing esaustivo è impossibile. Nonostante ciò un insieme ben scelto di casi di test può accrescere la nostra fiducia che il programma funziona come specificato. Un testing ben fatto può rivelare la maggior parte degli errori di un programma. Ci focalizziamo sul testing come metodo di validazione dei programmi. Vediamo come scegliere i casi di test e come organizzare il processo di testing

5 Testing Testing è il processo di eseguire un programma su un insieme di casi di test e di confrontare i risultati ottenuti con quelli attesi. Il suo scopo è di rivelare l’esistenza di errori. Il testing non indica dove sono gli errori, questo è fatto con il debugging. Quando facciamo il testing di un programma esaminiamo la relazione tra i suoi input e i suoi output. Quando ne facciamo il debugging prestiamo anche attenzione agli stati intermedi della computazione. La chiave per il successo del testing è la scelta dei dati di test appropriati. Il test esaustivo è impossibile per quasi tutti i programmi. Si deve allora trovare un insieme ragionevolmente piccolo di test che consenta di approssimare l’informazione che avremmo ottenuto con il testing esaustivo. Esempio. Consideriamo il programma che prende come argomento un intero e lavora in un modo su tutti gli interi pari e in un modo diverso su tutti gli interi dispari. In questo caso fare il testing del programma su un intero pari qualunque, su un intero dispari qualunque e su zero è una buona approssimazione a un testing esaustivo

6 Black-Box testing I casi di test sono generati considerando sia la specifica che l’implementazione del programma. Nel black-box testing i dati di test sono generati dalla sola specifica senza considerare la struttura interna del modulo sotto test. Questo approccio ha molti vantaggi. Il vantaggio piú importante è che il testing non è influenzato dalla componente sotto test. Se l’autore del programma ha fatto un assunto implicito invalido che il programma non sarebbe stato mai chiamato con una certa classe di input può aver omesso di includere il codice per trattare tale classe. Se il test fosse fatto esaminando il programma si potrebbe generare dati di test basati sull’assunto invalido. Un secondo vantaggio è la robustezza rispetto a cambiamenti dell’implementazione. I dati per il black-box testing non devono essere cambiati anche se sono stati fatti grossi cambiamenti al programma sotto test. Un vantaggio finale è che i risultati di un test possono essere interpretati da persone che non conoscono i programmi al loro interno.

7 Testing dei cammini (1) Un buon modo di generare dati di test è di esplorare cammini alternativi attraverso la specifica. Questi cammini si possono trovare mediante le causole REQUIRES e EFFECTS. Esempio. static float sqrt (float x, float epsilon) // REQUIRES: x >= 0 &&.00001 < epsilon <.001 // EFFECTS: Returns sq such that x - epsilon <= sq*sq <= x + epsilon. La clausola REQUIRES è la congiunzione di due termini: 1. x >= 0 2..00001 < epsilon <.001 Poiché il primo termine è la disgiunzione di due termini (x > 0 è un’abbreviazione per x = 0 or x > 0), può essere soddisfatto in due modi. Abbiamo cosí due vie per soddisfare la clusola REQUIRES: 1. x = 0 and.00001 < epsilon <.001 2. x > 0 and.00001 < epsilon <.001 Un insieme di dati di test per sqrt deve controllare ciascuno di questi casi.

8 Testing dei cammini (2) Esempio in cui la richiesta è una disgiunzione. static boolean isPrime (int x) // EFFECTS: If x is a prime returns true else retuns false. Vanno considerati entrambi i casi. Spesso i cammini attraverso la clausola EFFECTS riguardano il trattamento di errori. Non segnalare un’eccezione quando ci si trovi con un caso eccezionale è altrettanto grave quanto non dare il risultato giusto con un input normale. Perciò i dati dovrebbero far sí che tutte le eccezioni possibili siano sollevate. Esempio. static int search (int[ ] a, int x) throws NotFoundException, NullPointerException // EFFECTS: If a is null throws NullPointerException else if x is in a, // returns i such that a[i] = x, else throws NotFoundException. Dobbiamo includere test sia per il caso in cui x è in a che per quello in cui non lo è e per il caso in cui a è nullo.

9 Testing delle condizioni di confine Considerare tutti i cammini attraverso la clausola Requires controlla certe condizioni di confine (per esempio il caso in sqrt deve trovare la radice quadrata di zero), ma altre condizioni di confine non emergono da tale analisi. La verifica delle condizioni di confine consente il controllo di due tipi di errore: 1. Errori logici, in cui il cammino che deve trattare un caso speciale prsentato da una condizione di confine è omesso. 2. Mancato controllo di condizioni che possono causare il sollevamento di eccezioni o dal linguaggio o dal sistema hardware (per esempio overflow arimetico). Per generare test che consentano di rivelare il secondo tipo di errore è buona regola usare dati di test che coprano tutte le combinazioni dei valori piú grandi e piú piccoli consentiti per tutti gli argomenti numerici.

10 Errori dovuti a aliasing Un altro tipo di condizione di confine occorre quando due formali si riferiscono allo stesso oggetto mutabile. Esempio: static void appendVector (Vector v1, Vector v2) throws NullPointerException // MODIFIES: v1 and v2 // EFFECTS: If v1 or v2 is null throws NullPointerException else removes // all elements of v2 and appends them in reverse order to the end of v1. static void appendVector (Vector v1, Vector v2) { if (v1 == null) throws new NullPointerException ("Vectors.appendVector"); while (v2.size( ) > 0) { v1.addElement(v2.lastElement( )); v2.removeElementAt(v2.size( ) - 1); } } Dati di test che non includono un input in cui v1 e v2 si riferiscono allo stesso vettore non vuoto non rivelano un errore nell’implementazione.

11 Glass-Box testing (1) Il black-box testing è un buon punto di partenza per il testing ma raramente è sufficiente. Esempio. Prendiamo un programma che usa la ricerca tabellare per alcuni input e fa dei calcoli per altri input. Se i dati per il test black-box includono solo valori per cui è usata la ricerca tabellare, il testing non dà informazione sulla parte del programma che fa i calcoli. Perciò è necessario anche il glass-box testing in cui si tiene conto del codice del programma sotto test. Il glass-box testing dovrebbe supplementare il black-box testing con input che provano i diversi cammini nel programma. Lo scopo deve essere quello che ciascun cammino è provato da almeno un membro dell’insieme. Chiamiamo un tale insieme di dati di test path-complete.

12 Glass-Box testing (2) Consideriamo il programma: static int maxOfThree (int x, int y, int z) { if (x > y) if (x > z) return x; else return z; if (y > z) return y; else return z; } Nonostante che ci siano n 3 input, dove n è l’intervallo di interi consentito dal linguaggio di programmazione, ci sono solo quattro cammini nel programma. Perciò la proprietà di path-completeness ci porta a ripartire i dati di test in quattro classi. In una classe x è piú grande di y e z, in un’altra x è piú grande di y ma piú piccolo di z, etc.. Representativi delle quattro classi sono: 3, 2, 1 3, 2, 41, 2, 1 1, 2, 3

13 Glass-Box testing (3) E` facile vedere che la path-completeness non basta per trovare tutti gli errori. Esempio. Consideriamo il programma seguente: static int maxOfThree (int x, int y, int z) { return x; } Il test che contiene il solo input 2, 1, 1 è path complete per questo programma. Usando questo test saremmo portati a credere che il programma è corretto perché il test non rivela alcun errore. Qui si vede che va combinato il test che fa percorrere tutti i cammini del programma con la considerazione della specifica.

14 Glass-Box testing (4) Un altro potenziale problema con una strategia di testing basata sulla scelta di dati di test path-complete è che ci sono spesso troppi cammini differenti attraverso un programma perché il testing sia praticabile. Consideriamo il frammento di programma j = k; for (int i = 1; i <= 100; i++) if (Tests. pred (i * j)) j++; Ci sono 2 10 differenti cammini attraverso il programma e fare il testing di 2 10 cammini non è pratico. Dobbiamo accontentarci di un’approssimazione a dati di test path-complete. L’approssimazione piú comune è basata su considerare due o piú iterazioni attraverso un ciclo come equivalenti e due o piú chiamate ricorsive come equivalenti. Cosí troviamo un insieme di dati di test path-complete per il programma. Ci sono solo quattro cammini nel programma equivalente per lo scopo del testing. j = k; for (int i = 1; i <= 2; i++) if (Tests. pred(i * j) ) j++;

15 Glass-Box testing (5) Conclusioni: Includiamo sempre casi di test per ciascun ramo di un condizionale. Approssimiamo il testing path-complete per cicli e ricorsione come segue: Per cicli con un numero fissato di iterazioni (vedi esempio) usiamo due iterazioni. Scegliamo di percorrere il ciclo due volte e non una sola perché sono possibili errori dovuti a mancata possibile reinizializzazione dopo la prima volta che il ciclo è sttao percorso. Dobbiamo anche includere nei test tutti i possibili modi di terminare il ciclo. Per cicli con un numero di iterazioni variabile, includiamo nel test zero, una, due iterazioni e in aggiunta includiamo casi di test per tutti i possibili modi di terminare il ciclo. E` importante includere il caso in cui l’iterazione non sia fatta del tutto perché la mancata esecuzione del ciclo può essere sorgente di errori di programma. Per le procedure ricorsive includiamo casi di test che fanno ritornare dalla procedura senza nessuna chiamata ricorsiva e casi di test che provocano esattamente una chiamata ricorsiva. Test path-complete devono anche tenere in conto le eccezioni: per ogni istruzione dove potrebbe essere sollevata un’eccezione, ci deve essere un test per quel caso.

16 Test delle procedure (1) Esempio: Consideriamo una procedura per determinare se una stringa è una palindrome, ossia un stringa che si può leggere ugualmente in avanti e all’indietro (un esempio è ''deed'). static boolean palindrome (string s) throws NullPointerException // EFFECTS: If s is null throws NullPointerException, else returns // true if s reads the same forward and backward, else returns false. int low = 0; int high = s.length( ) -1; while (high > low) { if (s.charAt(low) != s.charAt(high)) return false; low ++; high --; } return true; } Dalla specifica vediamo che occorre un test per l’argomento nullo piú test che fanno restituire vero e falso. In aggiunta dobbiamo includere la stringa vuota e la stringa di un solo carattere come condizioni di confine. Questo potrebbe portare a scegliere per il test le stringhe " ", "d", "deed", "ceed".

17 Test delle procedure (2) L’esame del codice indica che dovremmo controllare i seguenti casi: 1. NullPointerException sollevata da una chiamata su length 2. Non esecuzione del ciclo 3. Restituzione di falso nella prima iterazione 4. Restituzione di vero dopo la prima iterazione 5. Restituzione di falso nella seconda iterazione 6. Restituzione di vero dopo la seconda iterazione I casi 1, 2, 3, 4 e 6 sono già coperti. Per il caso 5 potremmo prendere "aaba". A questo punto potremmo osservare che la sola stringa con un numero dispari di caratteri ne ha giusto uno. Perciò dovremmo aggiungere stringhe di test di lunghezza dispari. Infine dovremmo organizzare il test in un ordine ragionevole, con prima le stringhe piú corte.

18 Test degli iteratori Generare casi di test per gli iteratori è simile a generarli per le procedure. Il solo punto di interesse è che gli iteratori hanno nelle loro specifiche cammini che sono simili a quelli per i cicli. Dobbiamo includere casi di test in cui il generatore restituito dall’iteratore produce esattamente un risultato e produce due risultati, e se è possibile che non produca alcun risultato anche questo caso va incluso. Esempio. Iterator getPrimes (int n) // EFFECTS: Returns a generator that produces all primes less than or // equal to n (as Integers); if there are no such primes (i.e., n < 2) the // generator produces nothing. I casi di test potrebbero includere chiamate con n uguale a 1, 2 e 3. Se occorrono altri test può essere visto dall’implementazione dell’iteratore. Dobbiamo considerare tutti i cammini attraverso l’iteratore stesso e attraverso il suo costruttore e i suoi due metodi.

19 Test delle astrazioni di dato (1) Nel testing dei tipi di dato dobbiamo generare casi di test considerando specifica e implementazione di ciascuna operazione. Dobbiamo però fare il test delle operazioni in gruppo perché alcune operazioni (i costruttori e i mutatori) producono gli oggetti che sono usati nel test delle altre. Esempio. Nelle operazioni di IntSet il costruttore e i metodi insert e remove devono esser usati per generare gli argomenti per le altre operazioni e l’una per l’altra. Inoltre gli osservatori sono usati per il test di costruttori e mutatori. Per esempio isIn e size sono usati per esaminare gli insiemi prodotti da insert e remove. RepOk ha un ruolo speciale in questo test: dovremmo chiamarlo dopo ciascuna chiamata di un’operazione del tipo di dato (sia metodo che costruttore). Naturalmente deve restituire vero se l’implementazione è corretta.

20 Test delle astrazioni di dato (2) public class IntSet ( // OVERWIEW: IntSets are mutable, unbounded sets of Integers. // A typical IntSet is {x1,..., xn}. // constructors public IntSet // EFFECTS: Initializes this to be empty. // methods public void insert Int x) // MODIFIES: this // EFFECTS: Adds x to the elements of this, i.e., this-post = this + x public void remove (int x) // MODIFIES: this // EFFECTS: Removes x from this, i.e., this-post = this - x public boolean isIn (int x) // EFFECTS: If x is in this returns true else returns false. …………………………………………………………………………….

21 Test delle astrazioni di dato (3) ……………………………………………………………………………. public int size ( ) // EFFECTS: Returns the cardinality of this. public Iterator elements ( ) // EFFECTS: Returns a generator that produces all the elements of this // (as Integers), each exactly once, in arbitrary order. // REQUIRES: this must not be modified while the generator is in use.

22 Test delle astrazioni di dato (4) public class IntSet { private Vector els; // the rep public IntSet ( ) { els = new Vector( ); } public void insert (int x) { Integer y = new Integer(x); if (getIndex(y) < 0) els.add(y); } public void remove (int x) { int i = getIndex(new Integer(x)); if (i < 0) return; els.set (i, els.lastElement( )); els.remove (els.size( ) -1); } public boolean isIn (int x) {return getIndex (new Integer(x)) >= 0; } private int getIndex (Integer x) { // EFFECTS: If x is in this returns index where x appears // else returns -1. for (int i = 0; i < els.size( ); i++) if (x.equals(els.get(i))) return i; return -1; } public int size ( ) { return els.size( ); } }

23 Test delle astrazioni di dato (5) Cominciamo dai cammini nelle specifiche. Le specifiche di isIn e elements hanno cammini ovvii da essere esplorati. Per isIn dobbiamo generare casi di test che producono sia vero che falso come risultato. Poiché elements è un iteratore dobbiamo considerare almeno i cammini di lunghezza zero, uno e due. Perciò ci serviranno IntSet contenenti zero, uno e due elementi. L’ IntSet vuoto e IntSet di un solo elemento controllano condizioni di confine. Cosí per fare il test degli osservatori dobbiamo partire con i seguenti IntSet: L’IntSet vuoto prodotto chiamando il costruttore IntSet L’IntSet di un elemento prodotto inserendo 3 nell’insieme vuoto L’ IntSet di due elementi prodotto prodotto inserendo 3 e 4 nell’insieme vuoto. Per ciascuno faremo chiamate a isIn, size e elements e verificheremo i risultati. Nel caso di isIn, faremo chiamate in cui l’elemento è nell’insieme e altre in cui non lo è.

24 Test delle astrazioni di dato (6) Non abbiamo esaminato ancora il test di remove e non abbiamo ancora considerato i cammini in altre specifiche. Ci sono cammini nascosti. Per esempio size di un IntSet non cambia se inseriamo un elemento che è già nell’insieme e dobbiamo perciò considerare il caso in cui inseriamo l’elemento due volte. Similmente, size decresce quando rimuoviamo un elemento soltanto se l’elemento è nell’insieme, cosí dobbiamo considerare un caso in cui rimuoviamo un elemento dopo averlo inserito e un altro in cui rimuoviamo un elemento che non è nell’insieme. Potremmo usar questi Intset: L’insieme ottenuto inserendo 3 due volte nell’insieme vuoto L’insieme ottenuto inserendo 3 e poi rimuovendo 3 L’insieme ottenuto inserendo 3 e poi rimuovendo 4. Per trovare questi cammini nascosti dobbiamo cercare cammini nei mutatori. Cosí, insert deve funzionare sia che l’elemento sia già nell’insieme oppure no, e similmente per remove. Questo ci dà i casi detti.

25 Test delle astrazioni di dato (7) In aggiunta dobbiamo cercare i cammini nelle implementazioni delle operazioni. I casi visti finora danno una buona copertura per l’implementazione che usa il vettore senza duplicazioni. Un problema si ha con isIn che contiene un ciclo implicitamente attraverso la chiamata a getIndex. Per coprire tutti i cammini in questo ciclo dobbiamo controllare il caso di un vettore di due elementi in cui non si ha nessun confronto positivo o un confronto positivo con il primo o con il secondo elemento. Non si possono trovare questi test considerando solo la specifica (al livello della specifica siamo solo interessati se l’elemento è nell’insieme oppure no e non ci interessa la posizione dell’elemento nel vettore). Similmente in remove dobbiamo essere sicuri di cancellare sia il primo che il secondo elemento del vettore.

26 Test delle astrazioni polimorfe Il testing delle astrazioni polimorfe è simile al testing delle loro controparti non generiche. Il solo problema è quanti tipi di parametri differenti occorre introdurre nel test. E` sufficiente un solo tipo di parametro perché l’astrazione polimorfa è indipendente dal particolare tipo di parametro che si usa. Quando l’astrazione parametrizzata usa un’interfaccia per esprimere richieste sui metodi dei parametri si richiederanno extra test black-box per maneggiare oggetti incomparabili. Per esempio i test di OrderedList includeranno il caso in cui si vuole aggiungere un elemento di un tipo, ad esempio String, e poi aggiungere un elemento di qualche tipo incomparabile, ad esempio Integer. Quando l’astrazione parametrizzata usa l’approccio del sottotipo relato è sufficiente fare il test con un sottotipo dell’interfaccia che esprime le richieste, insieme con il tipo di elemento relato. Per esempio per SumSet potremmo fare il test con PolyAdder e Poly. In aggiunta dobbiamo fare il test di chiamate i cui argomenti non sono oggetti del tipo relato. Un esempio è il caso in cui si tenta di inserire una String in un SumSet che usa un PolyAdder.

27 Test di una gerarchia di tipi (1) Quando si ha una gerarchia di tipi, i test black-box per un sottotipo devono includere quelli per il supertipo. L’approccio generale è di fare il test del sottotipo facendo i passi seguenti: test black-box del suo supertipo aumentato dalla chiamata dei costruttori del sottotipo test black-box addizionali per il sottotipo test glass-box per il sottotipo. I test black-box del supertipo devono essere basati su chiamate ai costruttori del sottotipo cosicché i test vengono fatti per oggetti del sottotipo. Infatti alcuni supertipi (quelli definiti da interfacce e classi abstratte) non hanno costruttori e i loro test sono semplicemente template che devono essere riempiti con le chiamate ai costruttori.

28 Test di una gerarchia di tipi (2) Per Iterator occorrono tre test; per il caso in cui hasNest restituisce falso immediatamente, o restituisce falso dopo la prima iterazione o restituisce falso dopo la seconda iterazione. Ciascun test dovrà verificare che hasNext restituisca il risultato atteso e che next si comporti consistentemente con hasNext. Per fare il test di un sottotipo particolare dovremo creare un oggetto del sottotipo come prima parte di ciascun caso di test. Cosí per fare il test di un iteratore specifico ci vorrà una chiamata che crea un generatore vuoto per il primo caso, una chiamata che restituisce un generatore che produce giusto un elemento per il secondo caso e una chiamata che restituisce un generatore che produce due elementi per il terzo caso. Può capitare che per qualche sottotipo non sia possibile eseguire tutti i test. Per esempio, per allPrimes non è possibile che hasNext restituisca falso. Perciò vanno tolti dai test del supertipo quei casi che non si possono presentare.

29 Test di una gerarchia di tipi (3) In aggiunta, ci saranno test black-box per il sottotipo. Questi saranno basati su tutti i costruttori del sottotipo. Ci sono due sorgenti per questi test: 1. Ci devono essere test per i metodi ereditati le cui specifiche sono cambiate. Se il metodo del sottotipo ha una precondizione piú debole, i suoi test black-box includeranno i casi che sono consentiti dalla sua precondizione ma non dalla precondizione del metodo del supertipi. Similmente, se il metodo del sottotipo ha una postcondizione piú forte andrà fatto il test dei casi extra. Per esempio, i test per l’iteratore elements per SortedIntSet devere verificare che gli elementi siano prodotti nell’ordine. Per il generatore restituito da allPrimes vorremo controllare che produce veramente numeri primi e non ne tralascia nessuno. 2. Ci devono essere test per i metodi extra. Siamo interessati in due cose: come i metodi extra interagiscono con i metodi del supertipo e l’effetto dei metodi extra. Per esempio, per MaxIntSet ci saranno test per assicurare che max non modifica l’insieme e anche che verificano che max restituisce il risultato giusto. Il sottotipo avrà anche i suoi test glass-box, ma non è necessario per il test del sottotipo usare i test glass-box per la sua superclasse.

30 Test di una gerarchia di tipi (4) Quando il supertipo è definito da una classe concreta si farà il test nel modo normale e quando è definito da un’interfaccia non se ne farà il test perché non ha codice. Un supertipo definito da una classe astratta ha qualche codice e perciò ha i suoi test glass-box. Vorremmo fare il test della classe astratta cosí da poter ignorare i suoi test glass-box piú tardi quando facciamo il test delle sue sottoclassi. Tuttavia i test possono essere fatti solo fornendo una sottoclasse concreta. Questa sottoclasse potrebbe essere una sottoclasse che si ha intenzione di implementare o potrebbe essere uno stub, cioè una implementazione molto semplice di una sottoclasse. L’implementazione deve esser abbastanza completa che possano essere eseguiti tutti i test della superclasse, sia black-box che glass-box. Esempio. Per fare il test della classe astratta IntSet ci occorre memorizzare gli elementi. Perciò può esser meglio usare una sottoclasse reale per il testing della superclasse.

31 Test di una gerarchia di tipi (5) Extra controllo può occorrere quando la gerarchia è usata per fornire implementazioni multiple di un tipo. Se i sottotipi sono uno indipendente dall’altro, il testing è semplice perché non ci sono extra metodi e il comportamento dei metodi ereditati non cambia. Ma quando i sottotipi non sono indipendenti occorre farne il test congiuntamente o simularne uno mentre si fa il test dell’altro. Esempio. Consideriamo le implementazioni densa e sparsa di Poly e supponiamo di voler fare il test di DensePoly. Il problema è che vari metodi di DensePoly fanno chiamate a metodi di SparsePoly. Dobbiamo tenerne conto in qualche modo. Inoltre nascono extra test black-box riguardanti se occorre la giusta scelta della rappresentazione (sparsa o densa) ogni volta che si crea un nuovo Poly (come ad esempio nel metodo add). Questi sono test black-box piuttosto che test glass-box perché i criteri per la scelta sono parte delle specifiche del sottotipo.

32 Strumenti per il testing (1) Quello che possiamo automatizzare sono i processi di invocazione di un programma con una sequenza predefinita di input e la verifica dei risultati con una sequenza predefinita di test per l’accettabilità dell’output. Un meccanismo che fà questo è chiamato test driver. Un driver dovrebbe chiamare l’unità sotto test e tener traccia di come si comporta. Piú precisamente dovrebbe: 1. Creare l’ambiente necessario a chiamare l’unità sotto test. Questo può richiedere la creazione e l’inizializzazione di certe variabili globali, il creare e aprire certi file. 2.Fare una serie di chiamate. Gli argomenti delle chiamate potrebbero essere letti da un file o far parte del codice del driver. Se gli argomenti sono letti da un file si dovrebbe verificare se sono appropriati. 3.Salvare i risultati e verificare se sono appropriati.

33 Strumenti per il testing (2) Il modo piú comune per verificare se i risultati sono appropriati è di confrontarli con un a sequenza di risultati attesi che è stata memorizzata in un file. Qualche volta è meglio scrivere un programma che confronta direttamente i risultati sull’input. Per esempio se un programma deve trovare la radice di un polinomio è facile scrivere un driver che verifica se i valori restituiti sono radici oppure no. Similmente è facile verificare i risultati di sqrt facendo un calcolo. Spesso oltre che i driver il testing usa stub. Un driver simula la parte del programma che chiama l’unità sotto test, lo stub simula le parti del programma chiamate dall’unità sotto test. Uno stub deve: 1. Controllare la ragionevolezza dell’ambiente fornito dal chiamante 2. Controllare la ragionevolezza degli argomenti passati dal chiamante 3.Modificare gli argomenti e l’ambiente e restituire valori cosicché il chiamante possa proseguire. E` meglio se questi effetti si accordano con la specifica dell’unità che lo stub simula. Questo non è sempre possibile, il valore "giusto" si può trovare solo scrivendo il programma che lo stub deve rimpiazzare e ci si deve accontentare di un valore "ragionevole".

34 Testing di unità, di integrazione e di regressione Il testing di unità fà il test di un singolo modulo isolato dagli altri. Richiede: - un driver che fà il test automatico del modulo - stub che simulano il comportamento di tutti i moduli che il modulo usa. Il testing di integrazione fà il test di un gruppo di muduli assieme. Il testing di regressione consiste nell’eseguire di nuovo tutti i test dopo che ciascun errore è stato corretto.

35 Debugging Debugging è il processo di capire e correggere gli errori. Quando facciamo il debugging cerchiamo di restringere l’ambito del problema cercando semplici casi di test che manifestano l’errore e a cercare valori intermedi che aiutino a localizzare nel codice la regione responsabile dell’errore. Come raccogliamo evidenza sull’errore formuliamo ipotesi che tentiamo di refutare eseguendo test ulteriori. Quando pensiamo di capire le cause dell’errore studiamo la regione appropriata del codice per trovare e correggere l’errore.

36 Defensive programming Il debugging può esere facilitato se pratichiamo una programmazione "defensive" che consiste nell’inserire controlli nel programma per rivelare errori che potrebbero capitare. In particolare dovremmo controllare che sia soddisfatta la clausola REQUIRES. E` anche opportuno controllare l’invariante di rappresentazione. Questi controlli dovrebbero essere mantenuti, se possibile, nel codice di produzione.

37 Testing, debugging e defensive programming Testing è un modo per validare la correttezza del programma. Debugging è il processo di trovare e rimuovere errori. Defensive programming consiste nell’inserire dentro il programma controlli per rivelare errori e rende molto piú facile il debugging.