Question

Au travail, nous utilisons toujours JUnit 3 pour exécuter nos tests.Nous envisageons de passer à JUnit 4 depuis nouveau des tests sont en cours d'écriture mais je garde un œil sur TestNG depuis un moment maintenant.Quelles expériences avez-vous tous eues avec JUnit 4 ou TestNG, et laquelle semble mieux fonctionner pour un très grand nombre de tests ?Avoir de la flexibilité dans la rédaction des tests est également important pour nous puisque nos tests fonctionnels couvrent un large aspect et doivent être rédigés 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 de la flexibilité dans la façon dont le test peut être écrit, des assertions naturelles, un regroupement et des exécutions de tests facilement distribuées.

Était-ce utile?

La solution

J'ai utilisé les deux, mais je dois être d'accord avec Justin Standard sur le fait 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 possède une fonctionnalité intéressante qui vous permet de marquer les tests comme un groupe particulier, puis d'exécuter facilement tous les tests d'un groupe spécifique ou d'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 souhaitez des résultats rapides.Une suggestion tirée de leur documentation est de marquer certains sous-ensembles comme des tests "d'enregistrement" qui doivent ê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 la manquerez pas VRAIMENT.

Malgré toutes ses prétentions de configuration élevée, je me suis heurté à un cas de coin il y a quelques semaines où je ne pouvais pas faire ce que je voulais faire...J'aimerais pouvoir me souvenir de ce que c'est, mais je voulais en parler pour que vous sachiez que ce n'est pas parfait.

Le plus grand avantage de TestNG, ce sont les annotations...que JUnit a de toute façon ajouté dans la version 4.

Autres conseils

Tout d’abord, je dirais qu’il ne faut pas réécrire tous vos tests uniquement pour les adapter à la dernière mode.Junit3 fonctionne parfaitement bien, et l'introduction des annotations dans 4 ne vous rapporte pas grand chose (à mon avis).Il est bien plus important que vous les gars écrire tests, et il semble que vous le fassiez.

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

Je ne peux pas commenter TestNG car je ne l'ai pas utilisé.Mais je recommanderais unités, un excellent wrapper pour JUnit/TestNG/DBUnit/EasyMock, quel que soit l'itinéraire que vous empruntez.(Il prend en charge toutes les saveurs mentionnées ci-dessus)

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 finalement nous avons réalisé que TestNG n'avait pas de « fonctionnalités exceptionnelles ».C'est sympa et possède certaines 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 pour écrire des tests tout en apprenant à connaître TestNG, car 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'existe aucun outil décent qui ne le prenne en charge dès le départ, vous pouvez trouver beaucoup d'aide sur le Web et ils ont ajouté de nombreuses nouvelles fonctionnalités au cours de la dernière année, ce qui montre qu'il est vivant.

Nous avons décidé de nous en tenir à JUnit et nous n'avons jamais regretté notre choix.

Les plus grands atouts de TestNG pour moi incluent ses groupes de tests de support et, plus important encore, les dépendances des groupes de tests (le fait de marquer un test comme dépendant d'un groupe entraîne simplement l'exécution des 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'annotations et, plus que tout, la communauté d'utilisateurs dynamique et réactive.

Bien qu'à première vue, on ne pense pas que toutes les fonctionnalités de TestNG ci-dessus ne soient pas nécessaires, une fois que vous aurez compris 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).

Bravo à tout ce qui précède.Certaines autres choses que j'ai personnellement trouvées que j'aime davantage dans TestNG sont :

  1. Le @BeforeClass car TestNG a lieu après la création de la classe, vous n'êtes donc pas limité à pouvoir y appeler uniquement 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 j'ai juste un coup de pied en écrivant une série 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 !Au départ, j'en avais fait 4, mais beaucoup trop de pages sur lesquelles j'ai travaillé cassent le HtmlUnit conducteur pour une raison ou une autre.

Ouais, je dois probablement trouver cette vie.;)

Je voulais partager celui que j'ai rencontré aujourd'hui.J'ai trouvé que le coureur paramétré intégré est assez grossier dans Junit4 par rapport à TestNG (je sais que chaque framework a ses points forts mais quand même).L'annotation Junit4 @parameters est limitée à un seul ensemble de paramètres.J'ai rencontré ce problème en testant le comportement valide et invalide des fonctionnalités dans la même classe de test.Ainsi, la première méthode publique annotée statique qu’il trouve sera utilisée, mais il peut les trouver dans n’importe quel ordre.Cela nous amène à écrire différentes classes inutilement.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 de manière valide et invalide dans la même classe de test en plaçant séparément les données valides/invalides.J'irai avec TestNG.

Un autre avantage de TestNG est également la prise en charge des tests parallèles.À notre époque du multicœur, 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'assertion.Alors 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.

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 je lance ce groupe.Lorsque j'utilisais JUnit 3, je commentais les entrées de toutes les méthodes sauf celle que je voulais exécuter dans la méthode "suite", mais j'oubliais généralement de les décommenter avant l'enregistrement.Avec les groupes, je n'ai plus ce problème.

2) En fonction de 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 importe statiquement toutes les méthodes d'assertion TestNG.

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

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 progresser dans les tests de paramétrage, les tests de dépendances et les tests de suites (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 les grandes suites de tests.

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

In simple terms, TestNG = JUnit + lot more...So, Why debate ? go and grab TestNG :-)

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

J'aime l'intégration soignée et facile de TestNG avec Guice.

Votre question me semble double.D'un côté vous aimeriez comparer deux frameworks de tests, de l'autre vous aimeriez implémenter des tests facilement, avoir des assertions naturelles, etc...

Ok, tout d'abord, JUnit a rattrapé TestNG en termes de fonctionnalités, ils ont quelque peu comblé l'écart avec la v4, mais pas assez bien à mon avis.Des choses comme les annotations et les fournisseurs de données sont encore bien meilleures dans TestNG.Ils sont également plus flexibles en termes d’exécution de tests, puisque TestNG a des dépendances, des regroupements et des classements de tests.

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, à moins que vous ne vous concentriez sur les tests d'intégration/d'automatisation.D'après mon expérience, JUnit est conçu à partir de zéro pour les tests unitaires et est maintenant poussé vers des niveaux de tests plus élevés, ce qui, selon l'OMI, n'en fait pas le bon outil pour le travail.TestNG réussit bien aux tests unitaires et, grâce à sa fourniture de données robuste et à ses excellentes capacités d'exécution de tests, fonctionne encore mieux au niveau des tests d'intégration/automatisation.

Passons maintenant à ce que je crois être un problème distinct, comment écrire des tests bien structurés, lisibles et maintenables.La plupart de cela, je suis sûr que vous le savez, mais des choses comme Modèle d'usine, Modèle de commande et Objets de page (si vos sites Web de test) sont vitaux, il est très important d'avoir une couche d'abstraction entre ce qu'est votre test (SUT) et ce qu'est le test réel (assertions de logique métier).Afin d'avoir des assertions bien plus belles, vous pouvez utiliser Hamcrête.Utilisez l'héritage/les interfaces Javas pour réduire les répétitions et renforcer les points communs.

J'ai presque oublié, utilisez également le Modèle de générateur de données de test, ceci, associé à l'annotation du fournisseur de données de TestNG, est très utile.

Mon opinion 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.

Pourquoi utilisons-nous TestNG au lieu de JUnit ?

  1. La déclaration de @BeforeClass et @AfterClass la méthode doit être statique dans JUnit alors qu'il y a plus de flexibilité dans TestNG dans la déclaration de méthode, elle n'a pas ces contraintes.

  2. Dans TestNG, nous pouvons paramétrer les tests de 2 manières.Annotation @Parameter ou @DataProvider.

    je) @Paramètre pour les cas simples, où un mappage clé-valeur est requis. (les données sont fournies via un fichier XML)

    ii) @Fournisseur de données 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. Tests 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é son échec.

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

  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 alors que JUnit n'offre pas de moyen simple de le faire immédiatement.

  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(dependsOnMethods = { "dependOnSomething" })

Cette fonctionnalité n'existe pas dans JUnit

  1. 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-elles été exécutées, quelle entrée a été utilisée et les journaux de test complets.De plus, il exporte également le tout vers un fichier XML qui peut être utilisé pour créer votre propre modèle de rapport.

Du côté de 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 aux plugins.

Lien vers la ressource :

  1. Une comparaison rapide entre JUnit et TestNG
  2. JUnit contre.TestNG :Quel framework de test devriez-vous choisir ?

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

les deux sont presque identiques.TestNG a des fonctionnalités supplémentaires telles que des tests et des dépendances.veuillez trouver la capture d'écran ci-jointe pour obtenir la comparaison complète. Comparaison complète entre Juni5 et TestNG

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top