Les plus gros atouts de TestNG pour moi incluent ses groupes de test de support et, plus important encore, les dépendances de groupe de test (le fait de marquer un test comme étant dépendant d'un groupe fait que les tests sautent simplement l'exécution 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 commencerez à comprendre la flexibilité apportée à vos tests, vous vous demanderez comment vous avez fait face à JUnit.

(avis de non-responsabilité - 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).

Un autre avantage de TestNG est également la prise en charge des tests parallèles. À notre époque de multicœurs, 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 assert. Donc au lieu de

assertEquals(operation.getStatus(), Operation.Status.Active);

Vous pouvez é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.

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 ensemble de paramètres. J'ai rencontré ce problème lors du test du comportement valide et non valide pour la fonctionnalité dans la même classe de test. Ainsi, la première méthode annotée publique et 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 avec une manière valide et invalide dans la même classe de test en mettant les données valides/invalides séparément. J'irai avec TestNG.

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

1. Le @BeforeClass pour TestNG a lieu après la création de la classe, vous n'êtes donc pas contraint de ne pouvoir appeler que les méthodes statiques de votre classe.

2. Tests parallèles et paramétrés, peut-être que je n'ai pas assez de vie... mais je reçois juste un coup de pied en écrivant une série de tests Selenium, en acceptant un nom de pilote comme paramètre. Définissez ensuite 3 groupes de test parallèles, 1 chacun pour les pilotes IE, FF et Chrome, et regardez la course ! Au départ, j'en ai fait 4, mais beaucoup trop de pages sur lesquelles j'ai travaillé cassent le pilote HtmlUnit pour une raison ou une autre.

Ouais, j'ai probablement besoin de trouver cette vie. ;)