Testing delle classi Testing del software

20/12/16
Testing delle classi
Corso di Principi di Progettazione del Software, a.a. 2016/17
20 dicembre 2016
ing. Roberto Vergallo
1
Testing del software
■ Tradizionalmente, prima fase del testing “a mano”…
System.out.println(“Valore di a = ” + a);
■ …poi, test funzionali
2
1
20/12/16
Suite Test
■ Necessità di test automatici: tutti i Test sono raggruppati in
una “Suite” che deve poter essere eseguita
automaticamente e che cresce man mano che il sistema
viene sviluppato, aggiungendo sempre nuovi Test.
■ …Perché? Il poterli eseguire tutti in un tempo ragionevole
premendo un pulsante è importante per ottenere tutte le
volte che è necessario un feedback sull’integrità del
sistema.
3
Testing automatico
■ Per ottenere il massimo vantaggio dai Test, questi ultimi devono essere
eseguiti in modo automatico.
■ Un Test automatico deve essere in grado di:
1. eseguire senza intervento manuale le operazioni di generazione dei dati di Test
(Fixture)
2. l’elaborazione dei dati
3. la verifica dei risultati ottenuti
4. Eventualmente, la registrazione dei risultati.
■ Garanzia della ripetibilità dei test
– Se le classi coinvolte nel Test non vengono modificate, gli stessi Test ripetuti anche
diverse volte producono sempre gli stessi risultati.
– Questo non è garantito con altri tipi di test
4
2
20/12/16
Test di Unità
■ I Test di Unità vengono definiti e scritti dai programmatori durante lo
sviluppo del codice
■ Consentono di verificare il corretto funzionamento di ogni singolo
elemento del quale è costituito il sistema.
■ Tali unità corrispondono di solito ad una classe oppure ad un modulo
più complesso, per esempio un Package.
5
Junit - Introduzione
■ Framework Java per esecuzione di Test di Unità e
Regressione
– Il Test di Regressione ha come obiettivo quello di verificare che una
nuova versione di un programma non fallisca nessun test di quelli
già effettuati su versioni precedenti dello stesso
– Fornisce strumenti per verificare la validità di asserzioni
– Permette di eseguire più casi di test per un singolo metodo
– Permette di eseguire test in modo semplice e veloce (uso di test
Suite)
– Download JUnit: http://junit.org/index.htm
6
3
20/12/16
Junit – Guida all’Uso
■ JUnit rappresenta il Framework di Test più diffuso in
ambiente Java.
■ Le classi che compongono il Framework sono contenute
nella libreria junit.jar.
■ Per poter eseguire dei Test con JUnit è necessario scrivere
le classi di Test seguendo alcune regole.
– I metodi di Test, per essere riconosciuti come tali da JUnit, devono
avere un nome che inizia con “test”, ossia devono essere del tipo
testXXX .
7
Junit – Guida all’Uso (cont.)
■ Per creare test in JUnit bisogna definire un metodo pubblico
per ogni metodo da testare, facendolo precedere dalla
“annotation” @Test
■ Test definiti tramite l’uso della famiglia di ASSERTXXX()
–
–
–
–
–
assertTrue(<condizione>)
assertFalse(<condizione>)
assertEquals(<obj1>,<obj2>)
fail(<message>)
...
8
4
20/12/16
Esempio classe di Test
■ Una semplice classe di Test si presenta nel seguente
modo:
public class ProvaTest {
@Test
public void testMioMetodo() {
fail("Not yet implemented");
}
}
9
Suite Test
■ Un’altra caratteristica di JUnit è la possibilità di raggruppare
i Test in “Suite” e di eseguire tali Suite singolarmente o tutte
insieme.
■ Questa funzionalità è molto utile quando si deve verificare
la funzionalità dell’intero sistema, per esempio nella fase di
integrazione giornaliera.
– istanziare un oggetto di tipo TestSuite;
– aggiungere i test alla suite invocando il metodo addTest(Test)
sull'oggetto istanziato
10
5
20/12/16
setUp()
■ I dati sui quali vengono effettuate le elaborazioni all’interno di un
metodo di Test al fine di verificare il corretto funzionamento di una certa
parte del sistema, devono essere opportunamente definiti e inizializzati.
■
Se si individua un’insieme di variabili comuni a tutti i metodi di una
classe di Test, queste vengono inizializzate all’interno del metodo
setUp().
■ Tali variabili sono dette la “Fixture” del Test.
■ Il metodo setUp() viene richiamato da JUnit prima dell’esecuzione di
ciascun metodo di Test.
■ In questo modo, eventuali modifiche dei dati all’interno di un metodo
non avranno nessuna influenza sugli altri metodi di Test. Ovviamente
non si può fare affidamento su setUp() nei casi in cui non esista una
Fixture comune a tutti i metodi di Test.
11
tearDown()
■ Il metodo setUp() ha anche una controparte che è il metodo
tearDown().
■ Quest’ultimo viene richiamato da JUnit dopo l’esecuzione di
un qualunque metodo di Test, allo scopo di consentire al
programmatore il rilascio di eventuali risorse allocate nel
metodo setUp().
■ Per esempio, se all’interno del metodo setUp() viene aperta
una connessione a un Database, sarebbe conveniente
chiuderla all’interno del metodo tearDown() prima di
ricrearne un’altra per un altro metodo di Test.
12
6
20/12/16
Errori JUnit
■ JUnit prevede due tipi di errori: gli errori e i fallimenti.
■ I primi sono problemi gravi che bloccherebbero il
funzionamento del sistema, come l’Overflow di memoria o il
lancio di un’eccezione dovuta per esempio ad un File non
trovato,
■ mentre i secondi derivano dal non soddisfacimento di
condizioni richieste nel Test, come l’uguaglianza tra due
variabili.
13
Verifiche dei risultati
■ JUnit non richiede verifiche manuali dei risultati.
■ Dalla classe TestCase vengono ereditati per esempio i
metodi assertEquals() per la verifica dell’uguaglianza di
diversi tipi di dati.
■ Il Test si riconduce alla verifica dell’uguaglianza tra il
dato atteso e quello calcolato.
■ Se i due dati differiscono, verrà segnalato un fallimento con
la descrizione del problema e l’indicazione del punto in cui
si è verificato.
14
7
20/12/16
Metodi assertX
■ static void assertTrue(boolean test)
■ static void assertFalse(boolean test)
■ assertEquals(expected, actual)
■ assertSame(Object expected, Object actual)
■ assertNotSame(Object expected, Object actual)
■ assertNull(Object object)
■ assertNotNull(Object object)
■ fail()
15
8