Testng: L'annotation @Test(enabled=false) au niveau de la classe devrait désactiver toutes les méthodes de la classe

Salut Nicolas,

Vous devriez voir cela si vous n'utilisez aucune méthode @Test sur vos méthodes, mais dès que vous le faites (comme vous le faites dans votre exemple ci-dessus avec dataProvider), l'attribut enabled est remplacé et sa valeur par défaut est vrai, d'où le comportement que vous voyez.

Est-ce que ça a du sens?

Oui, merci Cédric.

Je suppose à tort que l'annotation @test(enabled=false) sur la classe exclut entièrement la classe de l'exécution

Je suis d'accord, c'est un peu contre-intuitif, mais il est trop tard pour changer maintenant, malheureusement...

Salut, Cédric !
Que diriez-vous d'ajouter un nouveau paramètre à l'annotation @Test et de l'appeler quelque chose comme "enabledClass" et de le rendre vrai par défaut ? Il doit être utilisé uniquement au niveau de la classe (enabledClass = false) pour désactiver toute la classe quelles que soient les annotations au niveau de la méthode et être ignoré, s'il est ajouté pour la méthode.
De cette façon, nous préserverions la compatibilité descendante et fournirions une fonctionnalité assez utile en même temps.
Si vous le souhaitez, je peux l'implémenter moi-même et fournir une pull request.
Merci d'avance!

@andronix83 ,

Je crains que cela ne rende les choses plus confuses maintenant que vous devez expliquer la différence subtile entre enabled et enabledClass .

Le comportement actuel de enabled n'est pas le plus intuitif mais cela ne semble pas être un problème en général, si j'en juge par le nombre de fois où ce problème a été évoqué (presque jamais).

Salut Cédric,

J'ai en fait rencontré ce problème pas plus tard que la semaine dernière. Je travaille sur un serveur Web qui s'appuie sur l'API Facebook Graph. J'avais une classe de test qui avait des méthodes de test reposant sur du code frappant l'API Graph, avec d'autres méthodes de test n'ayant pas du tout besoin de s'appuyer sur ce service. Ensuite, il y a eu une panne globale sur Facebook dans son ensemble pendant plus d'une heure. Cela a entraîné l'échec de certains des tests de cette classe.

Ce que j'espérais faire, afin de garder le reste de mon équipe de développement débloqué, était de désactiver immédiatement tous les tests sur cette classe, via une annotation @Test(enabled=false) au niveau de la classe. Bien sûr, cela n'a pas fonctionné. Au lieu de cela, j'ai dû désactiver chaque méthode de test défaillante une par une, ce qui me prenait plus de temps que souhaité, voire même nécessaire pour résoudre ce problème.

Idéalement, TestNG prend en charge une sorte de fonctionnalité similaire à l'annotation @Ignore de JUnit : http://junit.sourceforge.net/javadoc/org/junit/Ignore.html. Pour faire court, les développeurs souhaitent en effet cette fonctionnalité.

Merci.

@ecbrodie Ceci est déjà pris en charge (essayez-le !) mais il y a une mise en garde : chaque méthode individuelle qui a une annotation @Test réactivera le test.

@Test(enabled = false)
public class T {
  void f() {} // will not run
}

@Test(enabled = false)
public class T {
  <strong i="10">@Test</strong>
  void f() {} // WILL run!
}

Cela est dû à la sémantique selon laquelle les attributs au niveau de la méthode remplacent les attributs définis au niveau de la classe, donc l'annotation @Test au niveau de la méthode dit essentiellement @Test(enabled = true) puisque c'est la valeur par défaut...

Logique?

Salut @cbeust , merci pour cet exemple, mais c'était déjà la compréhension du problème, donc je pense que vous m'avez peut-être mal compris. Ce point que j'essayais de faire était, étant donné la sémantique actuelle de @Test(enabled=true/false) et le désir d'avoir un moyen de spécifier effectivement une substitution de enabled au niveau de la classe pour ignorer tout ce qui est défini dans la méthode niveau, il est peut-être temps de reconsidérer votre position contre l'ajout d'une sorte de valeur d'annotation enabledClass .

Vous semblez indiquer un certain mépris envers l'approche originale que vous avez adoptée avec la sémantique @Test(enabled). Si tel est bien le cas, alors pourquoi ne pas amener sa sémantique à quelque chose qui vous semble plus intuitif ?

D'accord, je pense qu'un @Test(enabledClass = false) aurait du sens et c'est le seul moyen de mettre en œuvre votre suggestion sans rompre la compatibilité descendante. Ça devrait être assez facile aussi.

Peut-être que vous ou @juherr seriez intéressé à soumettre un PR ?

Je ne le sens pas bien. Je n'aime pas l'idée d'ajouter un nouvel attribut qui n'est utilisé que sur la classe.
Ensuite, je pense que enable=false est une mauvaise pratique lorsqu'il est utilisé dans les sources car vous devrez modifier les sources lorsque vous voudrez exécuter les tests.
IMO, si vous souhaitez désélectionner une classe, testng.xml doit être utilisé à la place.
@ecbrodie Comment fais tu tes tests ?

BTW, ce que je propose à la place est de fournir une implémentation IAnnotationTransformer qui remplacera le comportement par défaut de enable=false sur la classe.
IAnnotationTransformer a juste à enable=false chaque test si sa classe a enable=false .
Cela ne brisera pas la compatibilité descendante et n'ajoutera pas de paramètre spécifique.
@cbeust Qu'en pensez-vous ?

@juherr Cool PR, c'est en effet très simple à faire avec un IAnnotationTransformer .

Ma seule préoccupation est que pour l'utilisateur, c'est un peu plus obscur à utiliser, par opposition à un attribut enabledClass .

Notez que nous avons déjà quelques attributs qui ne sont applicables qu'au niveau de la classe ( suiteName , testName ).

Comme je l'ai dit, je n'aime pas le cas d'utilisation. Et je suppose que ce sera suffisant pour les 2 seules personnes qui l'ont demandé au cours des 4 dernières années :)

@juherr Assez bien.

@ecbrodie Que pensez-vous de la RP ?

https://github.com/cbeust/testng/pull/816

@cbeust
Juste curieux. Et si nous fournissions un AnnotationTransformer intégré qui peut faire cela ?

Oui, c'est ce que propose le #816

@juherr
Merci d'avoir partagé ces informations de relations publiques. Une raison pour laquelle cela attend d'être fusionné ?

Que faire si j'ai un scénario comme ci-dessous :

@Test(groups = { "regression", "smoke" }, dependsOnGroups = { "Creation" })
public class EditName {

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class)
    public void TC_1(String Msg) throws Exception{
        System.out.println(Msg);
    }

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class, dependsOnMethods = { "TC_1" }))
    public void TC_2(String Msg) throws Exception{
        System.out.println(Msg);
    }
}

1. TC_1 et TC_2 appartiendront-ils aux deux groupes, régression et fumée ?
2. Est-ce que TC_1 et TC_2 dépendront tous les deux du groupe « Création » ?
3. Est-ce que TC_2 dépendra du groupe "Création" ainsi que TC_1, ou juste TC_1 ?

@Rameshwar-Juptimath Quelle est la relation entre votre échantillon et ce problème ?

En raison de ce comportement non intuitif de @Test au niveau de la classe et de la méthode.
Que faut-il recommander comme bonne pratique ?
Doit-on éviter d'utiliser les deux dans les tests ?
Puisque nous l'utilisons plus ou moins au niveau de la méthode pour avoir un fournisseur de données différent pour chaque cas, devrions-nous éviter de l'avoir sur la classe ?
Les pensées?

@aliciatang Le comportement est le même pour tous les attributs d'annotation : les valeurs de la méthode écraseront les valeurs de la classe.

Depuis la 6.13, vous pouvez utiliser @Ignore qui correspond au comportement que vous attendez. La documentation pour @Ignore peut être trouvée ici