JUnit 4 vs TestNG - Mise à jour 2013 - 2014
JUnit 4 et TestNG étaient auparavant comparables. Quels sont les avantages et les inconvénients des deux frameworks de test?
Je comparais TestNG à JUnit4 aujourd'hui, et le principal avantage que je peux souligner avec mon expérience limitée des frameworks de test est que TestNG dispose d'une manière plus élégante de gérer des tests paramétrés avec le concept de fournisseur de données.
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 (exécuté avec @RunWith(Parameterized.class)). Avec TestNG, vous pouvez avoir plusieurs fournisseurs de données dans une même classe de test. Ainsi, 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 une prise en charge immédiate de TestNG et JUnit. Cependant, Eclipse ne prend en charge que JUnit prêt à l'emploi et nécessite l'installation d'un plug-in TestNG pour le faire fonctionner.
Cependant, un problème plus gênant que j'ai rencontré avec TestNG est que vos classes de test doivent étendre PowerMockTestCase si vous utilisez PowerMock pour simuler des dépendances dans vos tests. Apparemment, il existe des moyens de configurer la fabrique d’objets que votre infrastructure de test doit connaître lors de l’utilisation de PowerMock via une méthode spéciale ou via le testng.xml _ définition de suite, mais ceux-ci semblent être cassés pour le moment. Je n'aime pas que les classes de test étendent les classes de cadre de test, cela semble être du bidouillage.
Si vous n'utilisez pas PowerMock, ce n'est pas un problème, bien sûr, mais au final, j'ai l'impression que JUnit4 est mieux pris en charge.
D'après mon expérience des deux frameworks, testng comporte quelques fonctionnalités pratiques que l'équipe de JUnit a refusé d'implémenter depuis plusieurs années. Je le préfère à JUnit pour cette raison. La conversion en testng est facile car elle supporte à peu près tout dans JUnit (il existe un plugin de conversion pour Eclipse même), la reconversion en JUnit n’est pas si géniale à cause de ces fonctionnalités manquantes.
Dans testng
@BeforeClass, Les mé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). Un jour, j’avais un projet JUnit où tous les tests de la base de données (quelques dizaines) initialisaient la base de données au tout 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. Pour résumer, chaque méthode de test doit avoir son propre support de test. Par conséquent, vous ne devez pas utiliser une 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. Valable, mais vraiment ennuyeux pour les tests d'intégration. TestNG donne le choix aux utilisateurs ici. Junit ne le veut pas, ce qui est agaçant.Les fournisseurs de données de test sont un peu plus flexibles que leurs équivalents JUnit. Vous pouvez spécifier pour chaque test quelle méthode de fournisseur de données doit fournir l'entrée au lieu d'utiliser une approche unique pour la classe entière, 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 d'avoir.
Vous pouvez marquer une classe avec
@TestDans testng, ce qui signifie que chaque méthode publique est un test. Dans Junit, vous devez copier/coller@TestSur chaque méthode.
Un inconvénient avec les deux est la façon dont hamcrest est fourni avec JUnit et la manière dont JUnit est fourni avec testng. Il y a des bocaux alternatifs 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 généralement des caractéristiques de moins en moins remarquables. Le mouvement BDD dans son ensemble semble avoir eu peu d'impact sur l'un ou l'autre des cadres, par exemple. En outre, JUnit aurait simplement pu adopter la plupart de ce que j'ai énuméré ci-dessus. Il n’ya aucune bonne raison technique pour que JUnit ne puisse implémenter aucune de ces choses; les personnes derrière JUnit ont juste choisi de ne pas mettre en œuvre ces choses. Les deux projets semblent également manquer de vision quant aux orientations futures et semblent heureux de procéder à des ajustements mineurs au cours des dernières années.
Je cherchais de bonnes raisons de passer de TestNG à JUnit et j’ai trouvé ceci diapositives de Tomek Kaczanowski qui répondait 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, n'oubliez pas que le framework ScalaTest ne dispose que de JUnitRunner pour exécuter vos tests scala En d’autres termes, vous avez le choix:
- Tests Java JUnit + Scala Les tests sont exécutés avec JUnitRunner => Meilleure intégration Gradle
- Java testNG tests + Scala Les tests sont exécutés avec Scala Runner => Intégration médiocre du Gradle, depuis scala le testeur est un simple tâche en bloc du point de vue de Gradle.
Vous pouvez utiliser Mockito comme cadre moqueur. Il s'intègre bien avec TestNG. Il n'est pas nécessaire d'étendre une classe pour utiliser Mockito avec TestNG. Votre code de test est ainsi moins couplé 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 et détaillés sans dépendance entre eux, vous pouvez utiliser JUnit.
Si votre portée nécessite des tests fonctionnels nécessitant ou non des dépendances et le partage de données (paramètres) entre les tests, sélectionnez TestNG. En outre, TestNG peut effectuer des tests unitaires similaires à JUnit. SO vous pouvez avoir une suite de tests unitaires et une suite de tests fonctionnels.