JUnit vs TestNG [fermé]

Au travail, nous utilisons encore JUnit 3 pour exécuter nos tests. Nous avons envisagé de passer à JUnit 4 pour de nouveaux tests en cours d'écriture, mais je garde un œil sur TestNG depuis un moment maintenant. Quelles expériences avez-vous tous vécues avec JUnit 4 ou TestNG, et qui semble mieux fonctionner pour un très grand nombre de tests? Avoir la flexibilité dans la rédaction des tests est également important pour nous car nos tests fonctionnels couvrent un large aspect et doivent être écrits de différentes manières pour obtenir des résultats.

Les anciens tests ne seront pas réécrits car ils font très bien leur travail. Ce que j'aimerais voir dans les nouveaux tests, c'est la flexibilité dans la façon dont le test peut être écrit, les assertions naturelles, le regroupement et les exécutions de test facilement distribuées.

J'ai utilisé les deux, mais je suis d'accord avec Justin Standard pour dire que vous ne devriez pas vraiment envisager de réécrire vos tests existants dans un nouveau format. Quelle que soit la décision prise, il est assez simple d'exécuter les deux. TestNG s'efforce d'être beaucoup plus configurable que JUnit, mais au final, ils fonctionnent tous les deux aussi bien.

TestNG a une fonctionnalité intéressante où vous pouvez marquer les tests comme un groupe particulier, puis exécuter facilement tous les tests d'un groupe spécifique, ou exclure les tests d'un groupe particulier. Ainsi, vous pouvez marquer les tests qui s'exécutent lentement comme dans le groupe «lent», puis les ignorer lorsque vous voulez des résultats rapides. Une suggestion de leur documentation est de marquer certains sous-ensembles comme des tests de "check-in" qui devraient être exécutés chaque fois que vous archivez de nouveaux fichiers. Je n'ai jamais vu une telle fonctionnalité dans JUnit, mais là encore, si vous ne l'avez pas, vous ne l'avez pas. t vraiment manquer.

Malgré toutes ses prétentions de haute configuration, je suis tombé sur un cas de coin il y a quelques semaines où je ne pouvais pas faire ce que je voulais faire ... J'aurais aimé pouvoir me souvenir de ce que c'est, mais je voulais en parler donc vous savez que ce n'est pas parfait.

Le plus grand avantage de TestNG est les annotations ... que JUnit a quand même ajoutées dans la version 4.

Tout d'abord, je dirais, ne réécrivez pas tous vos tests juste pour les adapter à la dernière mode. Junit3 fonctionne parfaitement bien, et l'introduction d'annotations dans 4 ne vous achète pas beaucoup (à mon avis). Il est beaucoup plus important que vous écriviez des tests, et cela ressemble à vous.

Utilisez ce qui vous semble le plus naturel et vous aide à faire votre travail.

Je ne peux pas faire de commentaire sur TestNG b / c je ne l'ai pas utilisé. Mais je recommanderais unitils , un excellent wrapper pour JUnit / TestNG / DBUnit / EasyMock, quelle que soit la route que vous empruntez. (Il prend en charge toutes les saveurs mentionnées ci-dessus)

Les plus grandes cartes de tirage de TestNG pour moi incluent ses groupes de test de support et, plus important encore, les dépendances de groupe de test (le fait de marquer un test comme dépendant d'un groupe fait simplement sauter les tests lorsque le groupe dépendant échoue).

Les autres grands atouts de TestNG pour moi incluent les paramètres de test, les fournisseurs de données, les transformateurs d'annotation et plus que tout - la communauté d'utilisateurs dynamique et réactive.

Alors qu'en surface, on pourrait ne pas penser que toutes les fonctionnalités de TestNG ci-dessus pourraient ne pas être nécessaires, une fois que vous aurez commencé à comprendre la flexibilité apportée à vos tests, vous vous demanderez comment vous avez géré JUnit.

(avertissement - je n'ai pas du tout utilisé JUnit 4.x, je ne peux donc pas vraiment commenter les avancées ou les nouvelles fonctionnalités).

Il y a environ un an, nous avons eu le même problème. J'ai passé un certain temps à réfléchir à quel mouvement était le meilleur, et nous avons finalement réalisé que TestNG n'avait pas de `` fonctionnalités géniales ''. C'est sympa et a quelques fonctionnalités que JUnit 4 n'a pas, mais nous n'en avons pas besoin.
Nous ne voulions pas que les gens se sentent mal à l'aise d'écrire des tests tout en apprenant à connaître TestNG parce que nous voulions qu'ils continuent à écrire beaucoup de tests.
De plus, JUnit est à peu près le standard de facto dans le monde Java. Il n'y a pas d'outil décent qui ne le prend pas en charge depuis la boîte, vous pouvez trouver beaucoup d'aide sur le Web et ils ont ajouté de nombreuses nouvelles fonctionnalités au cours de l'année écoulée, ce qui montre qu'il est vivant.

Nous avons décidé de rester avec JUnit et n'avons jamais regardé en arrière.

Bravo à tout ce qui précède. Certaines autres choses que j'ai personnellement trouvées et qui me plaisent le plus dans TestNG sont:

1. Le @BeforeClassfor TestNG a lieu après la création de la classe, vous n'êtes donc pas contraint de ne pouvoir appeler que les méthodes statiques de votre classe.

2. Tests parallèles et paramétrés, peut-être que je n'ai tout simplement pas assez de vie ... mais je reçois juste un coup de pied en écrivant un ensemble de tests Selenium, en acceptant un nom de pilote comme paramètre. Ensuite, définissez 3 groupes de tests parallèles, 1 chacun pour les pilotes IE, FF et Chrome, et regardez la course! J'en ai fait 4 à l'origine, mais beaucoup trop de pages sur HtmlUnitlesquelles j'ai travaillé cassent le pilote pour une raison ou une autre.

Ouais, j'ai probablement besoin de trouver cette vie. ;)

Je voulais partager celui que j'ai rencontré aujourd'hui. J'ai trouvé que le runner paramétré intégré est assez grossier dans Junit4 par rapport à TestNG (je sais que chaque framework a ses avantages mais quand même). L'annotation Junit4 @parameters est limitée à un ensemble de paramètres. J'ai rencontré ce problème lors du test du comportement valide et non valide pour la fonctionnalité dans la même classe de test. Ainsi, la première méthode annotée publique et statique qu'il trouve sera utilisée, mais il peut les trouver dans n'importe quel ordre. Cela nous amène à écrire inutilement différentes classes. Cependant, TestNG fournit un moyen propre de fournir différents types de fournisseurs de données pour chaque méthode. Nous pouvons donc tester la même unité de code avec une manière valide et invalide dans la même classe de test en mettant séparément les données valides / invalides. J'irai avec TestNG.

Un autre avantage de TestNG est la prise en charge des tests parallèles. À notre époque de multicœurs, c'est important, je pense.

J'ai également utilisé les deux frameworks. Mais j'utilise hamcrest pour les affirmations. Hamcrest vous permet d'écrire facilement votre propre méthode d'assert. Donc au lieu de

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

Tu peux écrire

assertThat(operation, isActive());

Cela vous donne la possibilité d'utiliser un niveau d'abstraction plus élevé dans vos tests. Et cela rend vos tests plus robustes.

JUnit 4 Vs TestNG - Comparaison par mkyong.com (mis à jour en 2013).

Conclusion: je suggère d'utiliser TestNG comme cadre de test unitaire principal pour le projet Java, car TestNG est plus avancé dans les tests de paramétrage, les tests de dépendance et les tests de suite (concept de regroupement).

TestNG est destiné aux tests fonctionnels de haut niveau et aux tests d'intégration complexes. Sa flexibilité est particulièrement utile avec de grandes suites de tests.

En outre, TestNG couvre également l'ensemble des fonctionnalités de base de JUnit4 . Ce n'est plus une raison pour moi d'utiliser JUnit.

En termes simples, TestNG = JUnit + beaucoup plus. Alors, pourquoi débattre? allez chercher TestNG :-)

Vous pouvez trouver une comparaison plus détaillée ici .

Quelques ajouts à la réponse de Mike Stone:

1) La chose la plus fréquente pour laquelle j'utilise les groupes de TestNG est lorsque je souhaite exécuter une seule méthode de test dans une suite de tests. J'ajoute simplement ce test au groupe "phil", puis j'exécute ce groupe. Quand j'utilisais JUnit 3, je commentais les entrées pour toutes les méthodes, mais celle que je voulais exécuter dans la méthode "suite", mais j'oublierais généralement de les décommenter avant l'enregistrement. Avec les groupes, je n'ai plus ce problème.

2) Selon la complexité des tests, la migration des tests de JUnit3 vers TestNG peut être effectuée de manière quelque peu automatique avec sed et en créant une classe de base pour remplacer TestCase qui statique importe toutes les méthodes d'assert TestNG.

J'ai des informations sur ma migration de JUnit vers TestNG ici et ici .

Pourquoi utilisons-nous TestNG au lieu de JUnit?

1. La déclaration de @BeforeClasset @AfterClassméthode doit être statique dans JUnit alors que, il y a plus de flexibilité dans TestNG dans la déclaration de méthode, il n'a pas ces contraintes.

2. Dans TestNG, nous pouvons paramétrer les tests de 2 façons . Annotation @Parameter ou @DataProvider.

   i) @Parameter pour les cas simples, où le mappage clé-valeur est requis (les données sont fournies via un fichier xml)

   ii) @DataProvider pour les cas complexes. En utilisant un tableau à 2 dimensions, il peut fournir des données.

3. Dans TestNG, puisque la méthode @DataProvider n'a pas besoin d'être statique, nous pouvons utiliser plusieurs méthodes de fournisseur de données dans la même classe de test.

4. Test de dépendance: dans TestNG, si le test initial échoue, tous les tests dépendants suivants seront ignorés et non marqués comme ayant échoué. Mais JUnit a marqué qu'il a échoué.

5. Regroupement: des tests uniques peuvent appartenir à plusieurs groupes, puis s'exécuter dans différents contextes (comme des tests lents ou rapides). Une fonctionnalité similaire existe dans les catégories JUnit, mais il manque les annotations @BeforeGroups / @AfterGroups TestNG qui permettent d'initialiser le test / de le démonter.

6. Parallélisme: Si vous souhaitez exécuter le même test en parallèle sur plusieurs threads, TestNG vous propose une annotation simple à utiliser, tandis que JUnit ne propose pas de moyen simple de le faire.

7. TestNG @DataProvider peut également prendre en charge XML pour alimenter des données, des CSV ou même des fichiers de texte brut.

8. TestNG vous permet de déclarer des dépendances entre les tests et de les ignorer si le test de dépendance n'a pas réussi.

@Test (dependOnMethods = {"dependOnSomething"})

Cette fonctionnalité n'existe pas dans JUnit

9. Rapports:

Les rapports TestNG sont générés par défaut dans un dossier de sortie de test qui comprend des rapports HTML avec toutes les données de test, réussies / échouées / ignorées, combien de temps ont-ils été exécutés, quelle entrée a été utilisée et les journaux de test complets. En outre, il exporte également tout dans un fichier XML qui peut être utilisé pour créer votre propre modèle de rapport.

Sur le front JUnit, toutes ces données sont également disponibles via XML, mais il n'y a pas de rapport prêt à l'emploi et vous devez vous fier à des plugins.

Lien de ressource:

1. Une comparaison rapide entre JUnit et TestNG
2. JUnit vs TestNG: quel cadre de test choisir?

Une bonne différence est donnée dans ce tutoriel côte à côte: TestNG Vs JUnit: Quelle est la différence?

Votre question me paraît double. D'une part vous aimeriez comparer deux frameworks de test, d'autre part vous aimeriez implémenter des tests facilement, avoir des assertions naturelles, etc ...

Ok, tout d'abord JUnit a joué un rattrapage avec TestNG en termes de fonctionnalités, ils ont comblé le fossé un peu avec la v4, mais pas assez bien à mon avis. Des choses comme les annotations et les fournisseurs de données sont toujours bien meilleures dans TestNG. De plus, ils sont plus flexibles en termes d'exécution des tests, puisque TestNG a des tests de dépendance, de regroupement et de classement.

JUnit nécessite toujours que certaines méthodes avant / après soient statiques, ce qui limite ce que vous pouvez faire avant l'exécution des tests, TestNG n'a jamais ce problème.

TBH, la plupart du temps les différences entre les deux frameworks ne signifient pas grand-chose, sauf si vous vous concentrez sur les tests d'intégration / d'automatisation. D'après mon expérience, JUnit est entièrement conçu pour les tests unitaires et est maintenant poussé vers des niveaux de test plus élevés, ce que l'OMI en fait le mauvais outil pour le travail. TestNG réussit bien aux tests unitaires et, en raison de sa fourniture de données robuste et de ses grandes capacités d'exécution de tests, fonctionne encore mieux au niveau des tests d'intégration / d'automatisation.

Maintenant, pour ce que je crois être une question distincte, comment écrire des tests bien structurés, lisibles et maintenables. La plupart de ce que je suis sûr que vous le savez, mais des choses comme modèle d' usine , Motif de commande et PageObjects (si vos sites d' essai) sont essentiels, il est très important d'avoir une couche d'abstraction entre ce que votre test (SUT) et ce que le test réel is (assertions de logique métier). Afin d'avoir des affirmations beaucoup plus agréables, vous pouvez utiliser Hamcrest . Utilisez l'héritage / les interfaces javas pour réduire les répétitions et renforcer les points communs.

Presque oublié, utilisez également le modèle de générateur de données de test , ce couplé à l'annotation du fournisseur de données de TestNG est très utile.

Mon avis sur ce qui rend TestNG vraiment beaucoup plus puissant:

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.