Il test è il processo di verifica della funzionalità dell'applicazione se funziona secondo i requisiti.
Il test unitario è il test di una singola entità (classe o metodo). I test unitari sono molto essenziali per ogni azienda di software per fornire un prodotto di qualità ai propri clienti.
L'esecuzione manuale dei casi di test senza alcun supporto di strumenti è nota come test manuale.
Il supporto dello strumento e l'esecuzione dei casi di test utilizzando lo strumento di automazione è noto come test di automazione.
Di seguito sono riportati gli svantaggi del test manuale:
Richiede tempo e noioso - Poiché i casi di test vengono eseguiti dalle risorse umane, è molto lento e noioso.
Enorme investimento nelle risorse umane: poiché i casi di test devono essere eseguiti manualmente, sono necessari più tester nei test manuali.
Meno affidabile - Il test manuale è meno affidabile poiché i test potrebbero non essere eseguiti con precisione ogni volta a causa di errori umani.
Non programmabile: non è possibile eseguire alcuna programmazione per scrivere test sofisticati che recuperano informazioni nascoste.
Di seguito sono riportati i vantaggi dei test automatizzati:
Fast - L'automazione esegue casi di test molto più velocemente delle risorse umane.
Less investment in human resources - I casi di test vengono eseguiti utilizzando lo strumento di automazione, quindi sono necessari meno tester nei test di automazione.
More reliable - I test di automazione eseguono esattamente la stessa operazione ogni volta che vengono eseguiti.
Programmable - I tester possono programmare test sofisticati per far emergere informazioni nascoste.
JUnit è un Regression Testing Framework utilizzato dagli sviluppatori per implementare unit test in Java, accelerare la velocità di programmazione e aumentare la qualità del codice.
Di seguito sono riportate le caratteristiche importanti di JUnit:
È un framework open source.
Fornisce annotazioni per identificare i metodi di prova.
Fornisce asserzioni per testare i risultati attesi.
Fornisce corridori di prova per l'esecuzione di test.
I test JUnit possono essere eseguiti automaticamente e controllano i propri risultati e forniscono un feedback immediato.
I test JUnit possono essere organizzati in suite di test contenenti casi di test e persino altre suite di test.
JUnit mostra l'avanzamento del test in una barra che è verde se il test sta andando bene e diventa rossa quando un test fallisce.
Uno Unit Test Case è una parte del codice che garantisce che l'altra parte del codice (metodo) funzioni come previsto. Per ottenere rapidamente i risultati desiderati, è necessario il framework di test .JUnit è il framework di unit test perfetto per il linguaggio di programmazione Java.
Un caso di test unitario scritto formale è caratterizzato da un input noto e da un output atteso, che viene elaborato prima dell'esecuzione del test. L'input noto dovrebbe testare una precondizione e l'output atteso dovrebbe testare una postcondizione.
Devono essere presenti almeno due casi di unit test per ogni requisito: un test positivo e un test negativo. Se un requisito ha dei requisiti secondari, ciascun requisito secondario deve avere almeno due casi di test positivi e negativi.
I test vengono scritti prima del codice durante lo sviluppo per aiutare i programmatori a scrivere il codice migliore.
Il debug del codice utilizzando system.out.println () porterà alla scansione manuale dell'intero output ogni volta che il programma viene eseguito per garantire che il codice esegua le operazioni previste. Inoltre, a lungo termine, ci vuole meno tempo per codificare i metodi JUnit e testarli sui file di classe.
Segui i passaggi seguenti:
Scarica l'ultima versione di JUnit, indicata di seguito come junit.zip.
Decomprimere il file di distribuzione junit.zip in una directory denominata% JUNIT_HOME%.
Aggiungi JUnit al classpath -
set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar
Testare l'installazione eseguendo i test di esempio distribuiti con JUnit (i test di esempio si trovano direttamente nella directory di installazione, non nel file junit.jar). Quindi digita semplicemente -
java org.junit.runner.JUnitCore org.junit.tests.AllTests
Tutti i test dovrebbero passare con un messaggio "OK". Se i test non vengono superati, verificare che junit.jar si trovi in CLASSPATH.
Segnalare più errori in un singolo test è generalmente un segno che il test fa troppo ed è uno unit test troppo grande. JUnit è progettato per funzionare al meglio con una serie di piccoli test. Esegue ogni test all'interno di un'istanza separata della classe di test. Segnala il fallimento ad ogni test.
JUnit 3.7 ha deprecato assert () e lo ha sostituito con assertTrue (), che funziona esattamente allo stesso modo. JUnit 4 è compatibile con la parola chiave assert. Se si esegue con l'opzione -ea JVM, le asserzioni non riuscite verranno segnalate da JUnit.
Il refactoring dei componenti J2EE per delegare la funzionalità ad altri oggetti che non devono essere eseguiti in un contenitore J2EE migliorerà la progettazione e la testabilità del software. Cactus è un'estensione JUnit open source che può essere utilizzata per il codice Java lato server di unit test.
JUnit Framework può essere facilmente integrato con uno dei seguenti:
- Eclipse
- Ant
- Maven
Il framework di test JUnit fornisce le seguenti importanti funzionalità:
- Fixtures
- Suite di test
- Corridori di prova
- Classi JUnit
L'apparecchiatura è uno stato fisso di un insieme di oggetti utilizzati come base per l'esecuzione dei test. Lo scopo di un dispositivo di prova è garantire che vi sia un ambiente ben noto e fisso in cui vengono eseguiti i test in modo che i risultati siano ripetibili. Include i seguenti metodi:
setUp () che viene eseguito prima di ogni invocazione di test.
metodo tearDown () che viene eseguito dopo ogni metodo di test.
Suite di test significa raggruppare alcuni casi di unit test ed eseguirli insieme. In JUnit, entrambe le annotazioni @RunWith e @Suite vengono utilizzate per eseguire il test della suite.
Test runner viene utilizzato per eseguire i casi di test.
Le classi JUnit sono classi importanti che vengono utilizzate per scrivere e testare JUnit. Alcune delle classi importanti sono:
Assert - Contiene una serie di metodi di asserzione.
TestCase - Contiene un test case che definisce l'apparecchiatura per eseguire più test.
TestResult - Contiene metodi per raccogliere i risultati dell'esecuzione di un test case.
TestSuite - È un composto di test.
Le annotazioni sono come meta-tag che puoi aggiungere al tuo codice e applicarli ai metodi o in classe. L'annotazione in JUnit ci fornisce informazioni sui metodi di test, quali metodi verranno eseguiti prima e dopo i metodi di test, quali metodi verranno eseguiti prima e dopo tutti i metodi, quali metodi o classi verranno ignorati durante l'esecuzione.
Segui i passaggi seguenti:
Imposta il CLASSPATH
Invoca il corridore -
java org.junit.runner.JUnitCore
Questa classe fornisce una serie di metodi di asserzione utili per la scrittura di test. Vengono registrate solo le asserzioni non riuscite.
Un TestResult raccoglie i risultati dell'esecuzione di uno scenario di test. È un'istanza del pattern Collecting Parameter. Il framework di test distingue tra fallimenti ed errori. Un errore è previsto e verificato con affermazioni. Gli errori sono problemi imprevisti come un'eccezione ArrayIndexOutOfBoundsException.
Una TestSuite è un composto di test. Gestisce una raccolta di casi di test.
L'annotazione Test dice a JUnit che il metodo public void a cui è collegata può essere eseguito come test case.
Diversi test richiedono oggetti simili creati prima di poter essere eseguiti. L'annotazione di un metodo public void con @Before fa sì che tale metodo venga eseguito prima di ogni metodo di test.
Se si allocano risorse esterne in un metodo Before, è necessario rilasciarle dopo l'esecuzione del test. L'annotazione di un metodo public void con @After fa sì che tale metodo venga eseguito dopo il metodo Test.
L'annotazione di un metodo void statico pubblico con @BeforeClass fa sì che venga eseguito una volta prima di uno qualsiasi dei metodi di test nella classe.
Questo eseguirà il metodo al termine di tutti i test. Questo può essere utilizzato per eseguire attività di pulizia.
Di seguito sono riportate alcune delle utilità dell'annotazione @Ignore:
Puoi facilmente identificare tutte le annotazioni @Ignore nel codice sorgente, mentre i test non annotati o commentati non sono così semplici da trovare.
Ci sono casi in cui non è possibile correggere un codice che non funziona, ma si desidera comunque che il metodo sia in giro, proprio in modo che non venga dimenticato. In questi casi @Ignore ha senso.
Di seguito è riportato come funziona la procedura di esecuzione di JUnit:
Prima di tutto il metodo annotato come @BeforeClass viene eseguito una sola volta.
Infine, il metodo annotato come @AfterClass viene eseguito una sola volta.
Il metodo annotato come @Before viene eseguito per ogni test case ma prima dell'esecuzione del test case.
Il metodo annotato come @After viene eseguito per ogni test case ma dopo l'esecuzione del test case.
Tra il metodo annotato come @Before e il metodo annotato come @After ogni test case viene eseguito.
I casi di test vengono eseguiti utilizzando la classe JUnitCore. JUnitCore è una facciata per l'esecuzione di test. Supporta l'esecuzione di test JUnit 4, test JUnit 3.8.xe miscele.
Junit fornisce una comoda opzione di Timeout. Se un test case richiede più tempo del numero di millisecondi specificato, Junit lo contrassegnerà automaticamente come non riuscito. Il parametro timeout viene utilizzato insieme all'annotazione @Test.
JUnit fornisce un'opzione per tracciare la gestione delle eccezioni del codice. Puoi verificare se un codice genera o meno l'eccezione desiderata. Il parametro previsto viene utilizzato insieme all'annotazione @Test come segue: @Test (previsto)
Junit 4 ha introdotto una nuova funzionalità Test parametrizzati. I test parametrizzati consentono allo sviluppatore di eseguire lo stesso test più e più volte utilizzando valori diversi.
Ci sono cinque passaggi che devi seguire per creare test parametrizzati
Annota la classe di test con @RunWith (Parameterized.class).
Crea un metodo statico pubblico annotato con @Parameters che restituisca una raccolta di oggetti (come array) come set di dati di test.
Creare un costruttore pubblico che accetti ciò che è equivalente a una "riga" di dati di test.
Crea una variabile di istanza per ogni "colonna" di dati di test.
Crea i tuoi casi di test utilizzando le variabili di istanza come origine dei dati di test.
Il test case verrà richiamato una volta per ogni riga di dati. Vediamo i test parametrizzati in azione.
Fixtures è uno stato fisso di un insieme di oggetti usati come base per l'esecuzione dei test. Lo scopo di un dispositivo di prova è garantire che vi sia un ambiente ben noto e fisso in cui vengono eseguiti i test in modo che i risultati siano ripetibili. Include:
setUp () che viene eseguito prima di ogni invocazione di test.
metodo tearDown () che viene eseguito dopo ogni metodo di test.
Compilare una classe di test JUnit è come compilare qualsiasi altra classe Java. L'unica cosa a cui devi fare attenzione è che il file JAR JUnit deve essere incluso nel classpath.
Se un metodo di prova JUnit viene dichiarato "privato", viene compilato correttamente. Ma l'esecuzione fallirà. Questo perché JUnit richiede che tutti i metodi di test debbano essere dichiarati come "pubblici".
Quando un metodo viene dichiarato "protetto", è possibile accedervi solo all'interno dello stesso pacchetto in cui è definita la classe. Quindi, per testare un metodo "protetto" di una classe di destinazione, definire la classe di test nello stesso pacchetto della classe di destinazione.
Quando un metodo viene dichiarato "privato", è possibile accedervi solo all'interno della stessa classe. Quindi non c'è modo di testare un metodo "privato" di una classe di destinazione da qualsiasi classe di test. Quindi è necessario eseguire manualmente i test di unità. Oppure devi cambiare il tuo metodo da "privato" a "protetto".
Se un metodo di prova JUnit viene dichiarato per restituire "String", la compilazione passerà ok. Ma l'esecuzione fallirà. Questo perché JUnit richiede che tutti i metodi di test debbano essere dichiarati per restituire "void".
Sì, puoi testare usando il metodo main (). Un ovvio vantaggio sembra essere che puoi testare la classe con la whitebox. Cioè, puoi testarne le parti interne (metodi privati per esempio). Non puoi farlo con i test unitari. Ma principalmente il framework di test verifica l'interfaccia e il comportamento dal punto di vista dell'utente.
No. Non abbiamo bisogno di scrivere una classe di test indipendente per ogni classe che deve essere testata. Se è presente un piccolo gruppo di test che condivide un dispositivo di test comune, è possibile spostare quei test in una nuova classe di test.
Il test runner mantiene forti riferimenti a tutte le istanze di test per la durata dell'esecuzione del test. Ciò significa che per un'esecuzione di test molto lunga con molte istanze di test, nessuno dei test può essere sottoposto a garbage collection fino alla fine dell'intera esecuzione di test. L'impostazione esplicita di un oggetto su null nel metodo tearDown (), ad esempio, consente la raccolta dei rifiuti prima della fine dell'intera esecuzione del test.
In uno unit test, gli oggetti fittizi possono simulare il comportamento di oggetti complessi, reali (non fittizi) e sono quindi utili quando un oggetto reale è poco pratico o impossibile da incorporare in uno unit test.
Lo stile di codifica comune per i test con oggetti fittizi è:
- Crea istanze di oggetti fittizi.
- Imposta lo stato e le aspettative negli oggetti fittizi.
- Richiama il codice di dominio con oggetti fittizi come parametri.
- Verifica la coerenza negli oggetti fittizi.
Di seguito sono riportate le estensioni JUnit:
Cactus
JWebUnit
XMLUnit
MockObject
Cactus è un semplice framework di test per il codice java lato server di unit testing (servlet, EJB, tag lib, filtri). L'intento di Cactus è quello di ridurre il costo di scrittura dei test per il codice lato server. Usa JUnit e lo estende. Cactus implementa una strategia in-container, il che significa che i test vengono eseguiti all'interno del container.
Cactus Ecosystem è composto da diversi componenti:
Cactus Framework è il cuore di Cactus. È il motore che fornisce l'API per scrivere i test Cactus.
I moduli di integrazione Cactus sono front-end e framework che forniscono modi semplici per utilizzare Cactus Framework (script Ant, plugin Eclipse, plugin Maven).
WebUnit è un framework di test basato su Java per applicazioni web. Avvolge framework di test esistenti come HtmlUnit e Selenium con un'interfaccia di test semplice e unificata per consentire di testare rapidamente la correttezza delle applicazioni web.
JWebUnit fornisce un'API Java di alto livello per la navigazione in un'applicazione web combinata con una serie di asserzioni per verificare la correttezza dell'applicazione. Ciò include la navigazione tramite collegamenti, l'immissione e l'invio di moduli, la convalida del contenuto della tabella e altre funzionalità tipiche dell'applicazione Web aziendale.
I semplici metodi di navigazione e le asserzioni pronte all'uso consentono una creazione di test più rapida rispetto all'utilizzo solo di JUnit o HtmlUnit. E se vuoi passare da HtmlUnit ad altri plugin come Selenium (presto disponibile), non c'è bisogno di riscrivere i tuoi test.
XMLUnit fornisce una singola classe di estensione JUnit, XMLTestCase e una serie di classi di supporto.
Le classi di supporto consentono di fare asserzioni su -
Le differenze tra due parti di XML (tramite le classi Diff e DetailedDiff).
La validità di un pezzo di XML (tramite la classe Validator).
Il risultato della trasformazione di un pezzo di XML utilizzando XSLT (tramite la classe Transform).
La valutazione di un'espressione XPath su un pezzo di XML (tramite classi che implementano l'interfaccia XpathEngine).
Singoli nodi in un pezzo di XML che vengono esposti da DOM Traversal (tramite la classe NodeTest).