JUnit 4 vs TestNG - Mise à jour 2013 - 2014 [fermé]

88

JUnit 4 et TestNG étaient auparavant comparables. Quels sont les avantages et les inconvénients des deux cadres de test?

ctekk
la source
Si vous regardez la comparaison des fonctionnalités, il y a un bon article de mkyong sur jUnit 4 Vs testNG Si vous souhaitez vous référer à la comparaison d'utilisation. Il y a un bel article de Kapil Hope qui aide!
Anshu
71
Je trouve des questions comme celle-ci extrêmement utiles sur SO ... Je voulais vous dire merci d'avoir pris le risque de le poser et félicitations de ne pas l'avoir fermé!
user1445967
Façon d'aller contre les goûts de votre public: D
ctekk
2
Revoir cette question après tant d'années. Le plus drôle, c'est que je sens la conspiration! Ma question était complètement centrée sur différentes fonctionnalités, puis il y a eu une édition "communautaire" qui a édité ma question en "pour et contre" et puis la question a été fermée en raison de l'opinion. Lmao.
ctekk

Réponses:

29

Je comparais TestNG et JUnit4 aujourd'hui, et le principal avantage que je peux souligner avec mon expérience limitée dans les frameworks de test est que TestNG a une manière plus élégante de gérer les tests paramétrés avec le concept de fournisseur de données.

Pour autant que je sache, avec JUnit4, vous devez créer une classe de test distincte pour chaque ensemble de paramètres que vous souhaitez tester avec (exécuté avec @RunWith(Parameterized.class)). Avec TestNG, vous pouvez avoir plusieurs fournisseurs de données dans une seule classe de test, de sorte que vous pouvez également conserver tous vos tests pour une seule classe dans une seule classe de test.

Jusqu'à présent, c'est la seule chose que je puisse souligner comme un avantage de TestNG par rapport à JUnit4.

Intellij IDEA inclut la prise en charge de TestNG et JUnit prête à l'emploi. Cependant, Eclipse ne prend en charge que JUnit prêt à l'emploi et a besoin d'un plugin TestNG installé pour le faire fonctionner.

Cependant, un problème plus ennuyeux que j'ai rencontré avec TestNG est que vos classes de test doivent s'étendre PowerMockTestCasesi vous utilisez PowerMock pour simuler les dépendances dans vos tests. Apparemment, il existe des moyens de configurer la fabrique d'objets que votre framework de test doit connaître lors de l'utilisation de PowerMock via une méthode spéciale, ou via la testng.xmldéfinition de la suite, mais ceux-ci semblent être cassés pour le moment. Je n'aime pas que les classes de test étendent les classes du framework de test, cela semble hackish.

Si vous n'utilisez pas PowerMock, ce n'est bien sûr pas un problème, mais dans l'ensemble, j'ai l'impression que JUnit4 est mieux pris en charge.

JeroenHoek
la source
5
Non pas qu'il existe des implémentations alternatives de tests paramétrés, par exemple code.google.com/p/junitparams Et si vous n'aimez aucun d'entre eux, vous pouvez écrire les vôtres - c'est ce que j'aime dans l'extensibilité de JUnit. ;)
Esko Luontola
17

Sur la base de mon expérience avec les deux frameworks, testng possède quelques fonctionnalités pratiques que l'équipe JUnit a refusé de mettre en œuvre depuis plusieurs années. Je le préfère à JUnit pour cette raison. La conversion en testng est facile car elle prend en charge à peu près tout dans JUnit (il existe même un plugin de conversion pour eclipse), la reconversion vers JUnit n'est pas si bonne à cause de ces fonctionnalités manquantes.

  • Dans testng, les @BeforeClassméthodes ne sont pas statiques et s'exécutent avant l'exécution des tests de cette classe plutôt que lorsque la classe de test est chargée (comportement JUnit). Une fois, j'ai eu un projet JUnit où tous les tests de base de données (quelques dizaines) ont initialisé la base de données dès le début, ce qui était un comportement assez idiot. Il y a eu beaucoup de débats pour et contre cela dans la communauté JUnit. L'essentiel était que chaque méthode de test devrait avoir son propre montage de test et que vous ne devriez donc pas avoir de méthode de style beforeAll non statique, car cela vous permettrait de définir sournoisement une variable d'instance une fois, puis de l'utiliser dans tous vos tests. Valide, mais vraiment ennuyeux pour les tests d'intégration. TestNG donne aux utilisateurs le choix ici. Junit ne le fait pas, de par sa conception, ce qui est ennuyeux.

  • Les fournisseurs de données de Testng sont un peu plus flexibles que l'équivalent JUnit. Vous pouvez spécifier par test quelle méthode de fournisseur de données doit fournir l'entrée au lieu d'avoir une approche unique pour toute la classe comme dans JUnit. Ainsi, vous pouvez avoir des fournisseurs de données de cas positifs et négatifs pour vos tests dans une classe. Très agréable à avoir.

  • Vous pouvez marquer une classe avec @Testin testng, ce qui signifie: chaque méthode publique est un test. Dans Junit, vous devez copier / coller @Testsur chaque méthode.

Un ennui avec les deux est la façon dont hamcrest est fourni avec JUnit et la façon dont JUnit est fourni avec testng. Il y a des pots modifiés dans maven qui n'ont pas ce problème.

Mon gros souci avec les deux frameworks est qu'ils semblent tous les deux avoir cessé d'évoluer. Les rejets sont de moins en moins fréquents et ont tendance à avoir des caractéristiques de moins en moins remarquables. L'ensemble du mouvement BDD semble avoir eu peu d'impact sur l'un ou l'autre de ces cadres par exemple. En outre, JUnit aurait simplement pu adopter la plupart de ce que j'ai énuméré ci-dessus. Il n'y a aucune bonne raison technique pour laquelle JUnit ne peut implémenter aucune de ces choses; les personnes derrière JUnit choisissent simplement de ne pas implémenter ces choses. Les deux projets semblent également manquer de vision des orientations futures et ils semblent heureux de ne faire que des ajustements mineurs au cours des dernières années.

Jilles van Gurp
la source
9

Je cherchais de bonnes raisons de changer TestNG sur JUnit et j'ai trouvé que ces diapositives de Tomek Kaczanowski abordaient très bien cette question. Tomek est l'auteur du livre Practical Unit Testing qui semble être très respecté par les développeurs et les testeurs.

MajiK
la source
1

Si vous travaillez sur un projet Java / Scala et que Gradle est votre outil de construction de choix, gardez à l'esprit que le ScalaTestframework n'a qu'à JUnitRunnerexécuter vos tests scala. En d'autres termes, vous avez le choix:

  • Tests Java JUnit + Tests Scala exécutés avec JUnitRunner => Meilleure intégration Gradle
  • Tests Java testNG + Tests Scala exécutés avec Scala Runner => Mauvaise intégration de Gradle, car Scala test runner est une tâche en bloc unique du point de vue de Gradle.
Ivan Balashov
la source
0

Vous pouvez utiliser Mockito comme cadre de simulation. Il s'intègre bien avec TestNG. Vous n'avez pas besoin d'étendre une classe pour utiliser Mockito avec TestNG. Votre code de test est moins couplé de cette manière et si pour une raison quelconque vous devez utiliser d'autres frameworks moqueurs, il est facile de le faire.

El Do
la source
7
Cette réponse est tout simplement totalement hors de propos pour la question ....
Adrian Shum
11
@AdrianShum Je pense que Konrad essayait de commenter le point de JeroenHoek sur l'intégration de PowerMock avec TestNG, car il ne semble pas avoir le privilège de «commentaire», je suppose qu'il a mis son commentaire comme réponse
Taoufik Mohdit
1
Cette réponse comprend mal ce qu'est PowerMock. Ce n'est pas un remplacement pour Mockito, mais un supplément qui permet à Mockito de se moquer de certaines choses que Mockito seul ne peut pas faire (méthodes statiques, classes finales).
stickfigure
0

En un mot..

Si votre champ d'application est limité à des tests unitaires détaillés sans dépendances entre eux, JUnit peut être utilisé.

Si votre champ d'application nécessite des tests fonctionnels qui peuvent / peuvent ne pas nécessiter des dépendances et le partage de données (paramètres) entre les tests, choisissez TestNG. En outre, TestNG peut effectuer des tests unitaires similaires à JUnit. Ainsi, vous pouvez avoir une suite de tests unitaires et une suite de tests fonctionnels.

nabster
la source