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

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

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.

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.

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.

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.

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.

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.