Scarica Introduzione a JUnit e più Sbobinature in PDF di Ingegneria del Software solo su Docsity!
Capitolo 1
JUnit Testing
Quando si parla di JUnit, ci si vuole riferire alla fase di testing di codice del nostro prodotto software; in particolare, si vuole vedere quanto il nostro software sia affidabile e, NON corretto. Come sappiamo, non è possibile avere un sistema corretto al 100 % appunto, vogliamo vedere la correttezza del nostro sistema ovvero, vogliamo testarlo per vedere se va in contro a fallimenti. Si va dunque, alla ricerca dei bug del nostro codice; perciò, deve essere fatto in maniera più precisa possibile
Un test per il codice può dunque avere due possibili risultati:
- Failed test: il test risulta fallito e, si è dimostrato che è presente un errore all’interno del codice
- Passed test: il test non ha trovato errori tuttavia, ciò significa che il codice è corretto solo per quella determinata condizione
1.1 JUnit
La libreria di java JUnit ha come idea, per aiutarci a fare testing in modo semplice, di eseguire il testing attraverso lo unit testing
1.1.1 Unit testing
Lo unit testing consiste nel cercare errori e, quindi, effettuare il testing su porzioni isolate di codice, classi o oggetti I comandi che JUnit offre per aiutarci a scrivere dei tests sono detti assert. L’idea alla base è quella di inserire gli assert all’interno del nostro codice per verificare se quello che ci aspettavamo risulta vera. Se accade il contrario, significa che il test non è passato
1.1.2 Architettura di JUnit
Di tutte le classi che compongono l’architettura di JUnit ciò che è essensiale è la classe TestRunner la quale, ci permette di mandare in esecuzione un test e, di poter visualizzarne i risultati
1.2 JUnit test class
Per poter effettuare un test bisogna creare una classe di test. Ogni metodo della classe di test deve essere "taggato" con: @Test, prima del metodo. In questo modo, solo i metodi con @Test saranno eseguiti quando si effettua il run della nostra classe di test
È buon uso dare come nome della classe TestNomeclasse e, dare ad ogni test un nome significativo rispetto a ciò che il test verifica
1.3 JUnit assertion
Gli assert ci permettono di verificare una certa condizione logica all’interno del nostro codice e, sono usati nei metodi di test, per verificare che non ci siano fallimenti
Gli assert che possiamo utilizzare sono:
- assertTrue(test). Fallisce se la condizione logica test risulta falsa
- assertFalse(test). Fallisce se la condizione logica test risulta vera
- assertEquals(expected, actual). Fallisce se i valori dati expected, actual non sono uguali
- assertSame(expected, actual) Fallisce se i valori dati expected, actual non sono uguali per (==)
- assertNotSame(expected, actual) Fallisce se i valori dati expected, actual sono uguali per (==)
- assertNull(value). Fallisce se value non è nullo
- assertNotNull(value). Fallisce se value è nullo
- fail(). Se all’interno di un metodo troviamo questo comando, in qualsiasi condizione, il test viene interrotto e dato per fallito
Ogni metodo può avere al suo interno una stringa, per mandare a video un messaggio nel caso in cui un test fallisse Es. assertEqual("message", value1, value2);
Figura 1.1: Esempio di una classe di test
1.3.1 Eseguire un test
Per eseguire un test basta semplicemente eseguire la nostra classe di test, come un JUnit test. "Tasto destro, "run as" JUnit test"
- Se il test è passato, la barra del test risulterà verde
- Se il test è fallito, la barra del test risulterà rossa
Il test in caso di fallimento darà automaticamente il perché il test è fallito, mostrando in console il perchè il test è fallito. Ad esempio, ci dice il valore attuale e, ci mostra il valore che attendavamo
1.5.1 Test di tortura
Scrivere dei test che siano molto brevi, di facile comprensione e, che vadino a testare un’operazione per volta. Infatti, fare 10 piccoli test, è preferibile piuttosto che ad un unico grande test. In questo caso i test dovrebbero minimizzare l’uso di: if/else, loops, switch e, non utilizzare proprio i try/catch
Tuttavia i test di tortura possono essere messi all’interno della nostra classe di test, solo come aggiunta di test semplici
1.5.2 Regression testing
Il regression testing è una tipologia i testing che deve essere effettuata a dei prodotti che avevano già superato il testing in precedenza e che, col passere del tempo hanno introdotto nuovi metodi o, hanno avuto cambiamenti di codice; è quindi necessario andare a testare ciò che già avevamo testato in precedsenza, per verificare se i vecchi bug sono ancora risolti e, magari scoprirne la presenza di nuovi Nella realtà, molti prodotti hanno una check-list di test che devono superare prima che la nuova versione sia resa funzionate
1.5.3 Test-driven development
Si parla di test-driven development quando, la scrittura dei test che un codice deve passare, è fatta prima che il codice stesso sia scritto. Quindi, prima si scrivono i test e, poi, si scrive il codice in modo tale che passi i test
1.6 Cattive abitudini che utilizziamo nei test case
- I test dovrebbero essere indipendenti gli uni dagli altri, in modo tale da poter essere eseguiti correttamente a prescindere dall’ordine di esecuzione
- Evitare che un test A chiami un test B
- Evitare di eseguire dei test su oggetti condivisi
- Figura 1.2: Riassunto comandi JUnit
