JUnit vs TestNG [chiuso]

Al lavoro attualmente stiamo ancora utilizzando JUnit 3 per eseguire i nostri test. Abbiamo preso in considerazione il passaggio a JUnit 4 per la scrittura di nuovi test, ma sto tenendo d'occhio TestNG da un po 'di tempo. Quali esperienze avete avuto con JUnit 4 o TestNG e quale sembra funzionare meglio per un numero molto elevato di test? Avere flessibilità nello scrivere i test è anche importante per noi poiché i nostri test funzionali coprono un ampio aspetto e devono essere scritti in vari modi per ottenere risultati.

I vecchi test non verranno riscritti in quanto fanno il loro lavoro bene. Ciò che mi piacerebbe vedere nei nuovi test è però la flessibilità nel modo in cui il test può essere scritto, affermazioni naturali, raggruppamento ed esecuzioni dei test facilmente distribuibili.

Ho usato entrambi, ma sono d'accordo con Justin Standard sul fatto che non dovresti davvero considerare di riscrivere i tuoi test esistenti in qualsiasi nuovo formato. Indipendentemente dalla decisione, è piuttosto banale eseguire entrambi. TestNG si sforza di essere molto più configurabile di JUnit, ma alla fine entrambi funzionano ugualmente bene.

TestNG ha una funzione accurata in cui è possibile contrassegnare i test come un determinato gruppo e quindi eseguire facilmente tutti i test di un gruppo specifico o escludere i test di un determinato gruppo. Pertanto, è possibile contrassegnare i test eseguiti lentamente come nel gruppo "lento" e quindi ignorarli quando si desidera ottenere risultati rapidi. Un suggerimento dalla loro documentazione è di contrassegnare alcuni sottoinsiemi come test di "checkin" che dovrebbero essere eseguiti ogni volta che si esegue il check-in di nuovi file. Non ho mai visto una tale funzione in JUnit, ma poi di nuovo, se non lo si possiede, non si ' t DAVVERO perdere.

Nonostante tutte le sue pretese di alta configurazione, un paio di settimane fa mi sono imbattuto in un caso angolare in cui non potevo fare quello che volevo fare ... Vorrei poter ricordare di cosa si tratta, ma volevo sollevarlo quindi sai che non è perfetto.

Il più grande vantaggio di TestNG è rappresentato dalle annotazioni ... che JUnit ha aggiunto comunque nella versione 4.

Per prima cosa direi, non riscrivere tutti i test solo per adattarsi all'ultima moda. Junit3 funziona perfettamente e l'introduzione delle annotazioni in 4 non ti compra molto (secondo me). È molto più importante che voi ragazzi scriviate dei test e sembra che lo facciate.

Usa tutto ciò che sembra più naturale e ti aiuta a portare a termine il tuo lavoro.

Non posso commentare TestNG b / c non l'ho usato. Ma consiglierei unitils , un ottimo wrapper per JUnit / TestNG / DBUnit / EasyMock, indipendentemente dal percorso che prendi. (Supporta tutti i sapori sopra menzionati)

Le più grandi carte di pesca di TestNG per me includono i suoi gruppi di test di supporto e, soprattutto, le dipendenze dei gruppi di test (contrassegnare un test come dipendente da un gruppo fa sì che i test saltino semplicemente in esecuzione quando il gruppo dipendente fallisce).

Le altre grandi carte di TestNG per me includono parametri di test, fornitori di dati, trasformatori di annotazioni e più di ogni altra cosa: la comunità di utenti vibrante e reattiva.

Mentre in superficie non si potrebbe pensare che tutte le funzionalità di TestNG di cui sopra potrebbero non essere necessarie, una volta che si inizia a capire la flessibilità apportata ai test, ti chiederai come hai affrontato JUnit.

(disclaimer - Non ho usato affatto JUnit 4.x, quindi non sono in grado di commentare realmente i progressi o le nuove funzionalità).

Circa un anno fa, abbiamo avuto lo stesso problema. Ho passato un po 'di tempo a considerare quale mossa fosse migliore e alla fine ci siamo resi conto che TestNG non ha "caratteristiche killer". È bello e ha alcune funzionalità che JUnit 4 non ha, ma non ne abbiamo bisogno.
Non volevamo che le persone si sentissero a disagio a scrivere test mentre conoscevano TestNG perché volevamo che continuassero a scrivere molti test.
Inoltre, JUnit è praticamente lo standard di fatto nel mondo Java. Non esiste uno strumento decente che non lo supporti dalla scatola, puoi trovare molto aiuto sul web e hanno aggiunto molte nuove funzionalità nell'ultimo anno che mostra che è vivo.

Abbiamo deciso di restare con JUnit e non abbiamo mai guardato indietro.

Saluti a tutto quanto sopra. Alcune altre cose che ho scoperto personalmente che mi piacciono di più in TestNG sono:

1. Il @BeforeClassTestNG si svolge dopo la creazione della classe, quindi non sei vincolato dalla possibilità di chiamare solo metodi statici della tua classe.

2. Test paralleli e con parametri, forse non ne ho abbastanza di una vita ... ma mi viene solo un calcio a scrivere un set di test al selenio, accettando il nome di un pilota come parametro. Quindi definire 3 gruppi di test paralleli, 1 ciascuno per i piloti IE, FF e Chrome e guardare la gara! All'inizio ho fatto 4, ma troppe pagine su cui ho lavorato rompono il HtmlUnitdriver per un motivo o per l'altro.

Sì, probabilmente è necessario trovare quella vita. ;)

Volevo condividere quello che ho incontrato oggi. Ho scoperto che il runner con parametri integrato è piuttosto grezzo in Junit4 rispetto al TestNG (so che ogni framework ha i suoi punti di forza ma comunque). L'annotazione Junit4 @parameters è limitata a un set di parametri. Ho riscontrato questo problema durante il test del comportamento valido e non valido per la funzionalità nella stessa classe di test. Quindi verrà utilizzato il primo metodo pubblico, annotato statico che trova, ma può trovarli in qualsiasi ordine. Questo ci induce a scrivere diverse classi inutilmente. Tuttavia TestNG fornisce un modo chiaro per fornire diversi tipi di provider di dati per ogni singolo metodo. Quindi possiamo testare la stessa unità di codice con modo valido e non valido nella stessa classe di test mettendo i dati validi / non validi separatamente. Andrò con TestNG.

Anche un altro vantaggio di TestNG è il supporto di test paralleli. Nella nostra era di multicore è importante, penso.

Ho anche usato entrambi i framework. Ma sto usando hamcrest per affermazioni. Hamcrest ti consente di scrivere facilmente il tuo metodo di asserzione. Quindi invece di

assertEquals(operation.getStatus(), Operation.Status.Active);

Tu puoi scrivere

assertThat(operation, isActive());

Ciò ti dà l'opportunità di utilizzare un livello più alto di astrazione nei tuoi test. E questo rende i tuoi test più solidi.

JUnit 4 Vs TestNG - Confronto di mkyong.com (aggiornato nel 2013).

Conclusione: suggerisco di utilizzare TestNG come framework di test delle unità principali per il progetto Java, perché TestNG è più avanzato nel test di parametrizzazione, test di dipendenza e test di suite (concetto di raggruppamento).

TestNG è pensato per test funzionali di alto livello e test di integrazione complessi. La sua flessibilità è particolarmente utile con grandi suite di test.

Inoltre, TestNG copre anche l'intera funzionalità JUnit4 di base . Non ho più motivo di usare JUnit.

In termini semplici, TestNG = JUnit + molto altro. Quindi, perché discutere? vai e prendi TestNG :-)

Puoi trovare un confronto più dettagliato qui .

Un paio di aggiunte alla risposta di Mike Stone:

1) La cosa più frequente per cui utilizzo i gruppi di TestNG è quando voglio eseguire un singolo metodo di test in una suite di test. Aggiungo semplicemente questo test al gruppo "phil" e quindi eseguo questo gruppo. Quando usavo JUnit 3, commentavo le voci per tutti i metodi, ma quello che volevo eseguire nel metodo "suite", ma poi dimenticavo di decommentarli prima del check-in. Con i gruppi, non ho più questo problema.

2) A seconda della complessità dei test, la migrazione dei test da JUnit3 a TestNG può essere eseguita in qualche modo automaticamente con sed e creando una classe base per sostituire TestCase che importa staticamente tutti i metodi di asserzione TestNG.

Ho informazioni sulla mia migrazione da JUnit a TestNG qui e qui .

Perché usiamo TestNG invece di JUnit?

1. La dichiarazione @BeforeClasse il @AfterClassmetodo devono essere statici in JUnit mentre, nel TestNG c'è più flessibilità nella dichiarazione del metodo, non ha questi vincoli.

2. In TestNG, possiamo parametrizzare i test in 2 modi . Annotazione @Parameter o @DataProvider.

   i) @Parameter per casi semplici, in cui è richiesta la mappatura dei valori chiave (i dati vengono forniti tramite file xml)

   ii) @DataProvider per casi complessi. Utilizzando una matrice bidimensionale, può fornire dati.

3. In TestNG, poiché il metodo @DataProvider non deve necessariamente essere statico, possiamo utilizzare più metodi del fornitore di dati nella stessa classe di test.

4. Test delle dipendenze: in TestNG, se il test iniziale ha esito negativo, tutti i test dipendenti successivi verranno ignorati, non contrassegnati come non riusciti. Ma JUnit ha segnato il fallimento.

5. Raggruppamento: i singoli test possono appartenere a più gruppi e quindi essere eseguiti in contesti diversi (come i test lenti o veloci). Una funzione simile esiste nelle categorie JUnit ma manca delle annotazioni TestNG @BeforeGroups / @AfterGroups che consentono di inizializzare il test / smontarlo.

6. Parallelismo: se desideri eseguire lo stesso test in parallelo su più thread, TestNG ti copre con un'annotazione semplice da usare, mentre JUnit non offre un modo semplice per farlo immediatamente.

7. TestNG @DataProvider può anche supportare XML per l'alimentazione di dati, CSV o file di testo semplice.

8. TestNG consente di dichiarare le dipendenze tra i test e di saltarle se il test delle dipendenze non è stato superato.

@Test (dependOnMethods = {"dependOnSomething"})

Questa funzionalità non esiste in JUnit

9. Segnalazione:

I report TestNG vengono generati per impostazione predefinita in una cartella di output di test che include report HTML con tutti i dati di test, passati / non riusciti / ignorati, per quanto tempo sono stati eseguiti, quale input è stato utilizzato e i log di test completi. Inoltre, esporta tutto in un file XML che può essere utilizzato per costruire il proprio modello di report.

Sul fronte JUnit, tutti questi dati sono disponibili anche tramite XML, ma non esiste un report predefinito e devi fare affidamento sui plugin.

Collegamento alle risorse:

1. Un confronto tra JUnit veloce e TestNG
2. JUnit vs. TestNG: quale framework di test scegliere?

Una buona differenza è data in questo tutorial fianco a fianco: TestNG Vs JUnit: Qual è la differenza?

La tua domanda mi sembra duplice. Da un lato ti piacerebbe confrontare due framework di test, dall'altro ti piacerebbe implementare i test facilmente, avere affermazioni naturali, ecc ...

Ok, in primo luogo JUnit ha giocato a recupero con TestNG in termini di funzionalità, ha colmato il divario rispetto alla v4, ma a mio avviso non abbastanza bene. Cose come annotazioni e dataprovider sono ancora molto meglio in TestNG. Inoltre, sono più flessibili in termini di esecuzione dei test, poiché TestNG ha dipendenze, raggruppamenti e ordini dei test.

JUnit richiede ancora che determinati metodi prima / dopo siano statici, il che limita ciò che è possibile fare prima dell'esecuzione dei test, TestNG non ha mai questo problema.

TBH, principalmente le differenze tra i due framework non significano molto, a meno che non ti concentri sui test di integrazione / automazione. JUnit dalla mia esperienza è costruito da zero per i test unitari e ora viene spinto verso livelli più alti di test, che IMO lo rende lo strumento sbagliato per il lavoro. TestNG si comporta bene nei test unitari e, grazie alla sua solida fornitura di dati e alle eccellenti capacità di esecuzione dei test, funziona ancora meglio a livello di test di integrazione / automazione.

Ora, per quello che credo sia un problema separato, come scrivere test ben strutturati, leggibili e mantenibili. La maggior parte di questo sono sicuro che lo sai, ma cose come Factory Pattern , Command Pattern e PageObjects (se i tuoi siti Web di test) sono vitali, è molto importante avere uno strato di astrazione tra ciò che il tuo test (SUT) e ciò che il test effettivo è (affermazioni della logica aziendale). Per avere delle affermazioni molto più belle, puoi usare Hamcrest . Utilizzare l'ereditarietà / le interfacce java per ridurre la ripetizione e applicare la comunanza.

Quasi dimenticato, utilizzare anche il modello Test Data Builder , questo accoppiato con l'annotazione del provider di dati di TestNG è molto utile.

La mia opinione su ciò che rende TestNG davvero molto più potente:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.