JUnit 4 vs TestNG - Aggiornamento 2013-2014 [chiuso]

JUnit 4 e TestNG erano comparabili. Quali sono i pro e i contro dei due framework di test?

Oggi stavo confrontando TestNG e JUnit4 e il vantaggio principale che posso sottolineare con la mia limitata esperienza nei framework di test è che TestNG ha un modo più elegante di gestire i test parametrizzati con il concetto di fornitore di dati.

Per quanto posso dire con JUnit4 devi creare una classe di test separata per ogni set di parametri con cui vuoi testare (eseguito con @RunWith(Parameterized.class)). Con TestNG puoi avere più fornitori di dati in una singola classe di test, così puoi conservare tutti i tuoi test per una singola classe anche in un'unica classe di test.

Finora questa è l'unica cosa che posso sottolineare come vantaggio di TestNG su JUnit4.

Intellij IDEA include il supporto per TestNG e JUnit pronto all'uso. Tuttavia, Eclipse supporta solo JUnit pronto all'uso e necessita di un plug-in TestNG installato per farlo funzionare.

Tuttavia, un problema più fastidioso che ho riscontrato con TestNG è che le tue classi di test devono essere estese PowerMockTestCasese stai usando PowerMock per simulare le dipendenze nei tuoi test. Apparentemente ci sono modi per configurare la fabbrica di oggetti di cui il framework di test deve conoscere quando si utilizza PowerMock tramite un metodo speciale o tramite iltestng.xml definizione suite, ma al momento sembrano non funzionanti. Non mi piace che le classi di test estendano le classi del framework di test, sembra un hack.

Se non usi PowerMock questo non è un problema ovviamente, ma tutto sommato ho l'impressione che JUnit4 sia supportato meglio.

Sulla base della mia esperienza con entrambi i framework, testng ha alcune comode funzionalità che il team di JUnit ha rifiutato di implementare per diversi anni. Lo preferisco a JUnit per questo motivo. La conversione in testng è facile poiché in pratica supporta praticamente tutto in JUnit (c'è anche un plug-in di conversione per eclipse), riconvertire in JUnit non è così eccezionale a causa di queste funzionalità mancanti.

• In testng i @BeforeClassmetodi non sono statici ed vengono eseguiti prima che i test in quella classe vengano eseguiti piuttosto che quando la classe di test viene caricata (il comportamento di JUnit). Una volta avevo un progetto JUnit in cui tutti i test del database (poche dozzine) inizializzavano il database proprio all'inizio, il che era un comportamento piuttosto idiota. C'è stato molto dibattito a favore e contro questo nella comunità JUnit. L'essenza era che ogni metodo di test dovrebbe avere il proprio dispositivo di test e quindi non dovresti avere un metodo di stile beforeAll non statico perché ciò ti consentirebbe di impostare di nascosto una variabile di istanza una volta e quindi di usarla in tutti i tuoi test. Valido, ma davvero fastidioso per i test di integrazione. TestNG offre agli utenti la scelta qui. Junit non lo fa, in base alla progettazione, il che è fastidioso.

• I fornitori di dati di test sono un po 'più flessibili dell'equivalente JUnit. È possibile specificare per test quale metodo del fornitore di dati dovrebbe fornire l'input invece di avere un approccio unico per l'intera classe come in JUnit. Quindi puoi avere fornitori di dati di casi positivi e negativi per i tuoi test in una classe. Molto bello avere.

• Puoi marcare una classe con @Testin testng, il che significa: ogni metodo pubblico è un test. In Junit è necessario copiare / incollare @Testsu ogni metodo.

Un fastidio con entrambi è il modo in cui hamcrest è in bundle con JUnit e il modo in cui JUnit è in bundle con testng. Ci sono barattoli alterati in Maven che non presentano questo problema.

La mia grande preoccupazione con entrambi i framework è che entrambi sembrano aver smesso di evolversi. I rilasci sono sempre meno frequenti e tendono ad avere caratteristiche sempre meno degne di nota. L'intero movimento BDD sembra aver avuto scarso impatto su entrambi i framework, per esempio. Inoltre, JUnit avrebbe potuto semplicemente adottare la maggior parte di ciò che ho elencato sopra. Non c'è una buona ragione tecnica per cui JUnit non può implementare nessuna di queste cose; le persone dietro JUnit scelgono semplicemente di non implementare queste cose. Entrambi i progetti sembrano mancare di una visione per le direzioni future e sembrano essere felici di fare solo piccole modifiche negli ultimi anni.

Stavo cercando una buona ragione per cambiare TestNG su JUnit e ho trovato queste diapositive di Tomek Kaczanowski che rispondevano molto bene a questa domanda. Tomek è autore del libro Practical Unit Testing che sembra essere molto rispettato da sviluppatori e tester.

Se lavori su un progetto Java / Scala e Gradle è il tuo strumento di compilazione preferito, tieni presente che il ScalaTestframework deve solo JUnitRunnereseguire i tuoi test di scala. In altre parole, hai una scelta:

• Test Java JUnit + Test Scala eseguiti con JUnitRunner => Migliore integrazione Gradle
• Test Java testNG + Test Scala eseguiti con Scala Runner => Scarsa integrazione con Gradle, poiché scala test runner è un singolo compito di massa dal punto di vista di Gradle.

Puoi usare Mockito come framework beffardo. Si integra perfettamente con TestNG. Non è necessario estendere alcuna classe per utilizzare Mockito con TestNG. Il codice di test è meno accoppiato in questo modo e se per qualsiasi motivo è necessario utilizzare altri framework di mocking è facile farlo.

In poche parole ..

Se l'ambito è limitato a test unitari dettagliati senza dipendenze tra di essi, è possibile utilizzare JUnit.

Se il tuo ambito richiede test funzionali che possono / non possono richiedere dipendenze e condivisione di dati (parametri) tra i test, seleziona TestNG. Inoltre, TestNG può eseguire test di unità simili a JUnit. Quindi puoi avere una suite di unit test e una suite di test funzionali.