JUnit 4 vs TestNG - mise à Jour 2013 - 2014

Question

Dans le passé, JUnit 4 mis en œuvre beaucoup de TestNGs fonctionnalités, mais je ne suis pas sûr de la façon égale les deux sont jusqu'à maintenant. Merci de me fournir une mise à jour sur ce que le reste TestNG avantages fonctionnels sur JUnit 4, pour que je puisse rattraper trop.

Ce qui concerne

Answer 1

Si vous êtes à la recherche à la fonctionnalité de comparaison, il y a un bon article par mkyong sur jUnit 4 Vs testNG

Si vous souhaitez faire référence à l'utilisation de la comparaison. Il y a un bel article par Kapil

Espérons que ça aide!

Answer 2

J'ai été en comparant TestNG et JUnit4 aujourd'hui, et le principal avantage que je peux sortir avec mon expérience limitée dans le test-cadres est qu'TestNG a une façon plus élégante de la manipulation paramétrées tests avec les données du fournisseur de concept.

Aussi loin que je peux dire avec JUnit4 vous devez créer une classe de test pour chaque jeu de paramètres que vous voulez tester (ran avec @RunWith(Parameterized.class)). Avec TestNG vous pouvez avoir plusieurs données-fournisseurs dans une seule classe de test, de sorte que vous pouvez garder tous vos tests pour une classe unique dans un seul test de la classe.

C'est pour l'instant la seule chose que je peux souligner un avantage de TestNG sur JUnit4.

Intellij IDEA inclut le support pour TestNG et JUnit hors de la boîte. Cependant, Eclipse ne supporte JUnit hors de la boîte et a besoin d'une installé le plugin TestNG pour le faire fonctionner.

Toutefois, une plus ennuyeux problème que j'ai rencontré avec TestNG est que vos classes de test nécessité d'étendre PowerMockTestCase si vous utilisez PowerMock de se moquer des dépendances dans vos tests. Apparemment, il ya des façons de configurer l'objet d'usine de votre framework de test doit connaître lors de l'utilisation de PowerMock via une méthode spéciale, ou par l'intermédiaire de l' testng.xml suite de définition, mais ceux qui semblent être brisé à l'instant. Je n'aime pas avoir de test-classes d'étendre test-cadre des classes, il semble hackish.

Si vous n'utilisez pas PowerMock ce n'est pas une question de cours, mais dans l'ensemble j'ai l'impression que JUnit4 est mieux pris en charge.

Answer 3

Basé sur mon expérience avec les deux cadres, testng a quelques fonctions qui junit équipe a refusé de mettre en œuvre depuis plusieurs années. Je la préfère à junit pour cette raison. La conversion à testng est facile, car fondamentalement il prend en charge presque tous les aspects de junit (il y a un convertisseur plugin pour eclipse même), la transformation de retour à junit n'est pas si grande en raison de ces fonctionnalités manquantes.

• Dans testng @BeforeClass méthodes ne sont pas statiques et avant d'exécuter les tests dans la classe que courir plutôt que lorsque la classe de test est chargé (junit comportement). Une fois, j'ai eu un junit projet où tous les tests de base de données (quelques dizaines) initialisé la base de données dès le début, ce qui est assez idiot comportement. Il y a eu beaucoup de débat pour et contre cette dans les junit communauté. L'essentiel, c'est que chaque méthode de test doit avoir son propre banc d'essai et, par conséquent, vous ne devriez pas avoir un beforeAll style méthode non statique parce que ce serait vous permettent d'sournoisement définir une variable d'instance une fois et ensuite l'utiliser dans tous vos tests. Valide, mais vraiment ennuyeux pour les tests d'intégration. TestNG donne aux utilisateurs le choix ici. Junit n'est pas, de par sa conception, ce qui est ennuyeux.

• Testng fournisseurs de données sont un peu plus souple que la junit équivalent. Vous pouvez spécifier pour chaque test, qui fournisseur de données méthode doit fournir l'entrée au lieu d'avoir une approche unique pour l'ensemble de la classe comme dans junit. De sorte que vous pouvez avoir des effets positifs et négatifs de cas fournisseurs de données pour vos tests dans une classe. Très agréable d'avoir.

• Vous pouvez marquer une classe avec @Test dans testng, ce qui signifie: chaque méthode publique est un test. Dans Junit vous avez besoin de copier/coller @Test sur chaque méthode.

Une gêne avec les deux est la façon hamcrest est livré avec junit et la façon junit est livré avec testng. Il y a des altérer les pots de maven qui n'ont pas ce problème.

Mon gros soucis avec les deux cadres, c'est qu'ils semblent tous deux avoir cessé d'évoluer. Les rejets sont de plus en plus de moins en moins fréquentes et ont tendance à avoir de moins en moins de caractéristiques remarquables. L'ensemble de la BDD mouvement semble avoir eu peu d'impact sur le cadre par exemple. Aussi, junit pourrait simplement avoir adopté la plupart de ce que j'ai énuméré ci-dessus. Il n'y a aucune raison technique qui junit ne peut pas mettre en œuvre l'une de ces choses; les gens derrière junit il suffit de choisir de ne pas mettre en œuvre ces choses. Les deux projets semblent être dépourvus d'une vision pour l'avenir des directions aussi bien et ils semblent être heureux simplement à faire de petits ajustements pour les quelques dernières années.

Answer 4

Je cherchais de bonnes raisons pour passer TestNG plus de JUnit et j'ai trouvé ce diapositives par Tomek Kaczanowski aborder cette question, très bien. Tomek est l'auteur de la Pratique de Tests Unitaires livre qui semble être respectés par les développeurs et les testeurs.

Answer 5

Vous pouvez utiliser Mockito comme se moquant de votre cadre. Il s'intègre bien avec TestNG. Vous n'avez pas à étendre une classe à utiliser Mockito avec TestNG. Vous code de test est moins couplée de cette façon et si pour une raison quelconque vous avez besoin d'utiliser d'autres se moquant de cadres, il est facile de le faire.