Testng: Die Annotation @Test(enabled=false) auf Klassenebene sollte alle Methoden in der Klasse deaktivieren

Hallo Nicolas,

Sie sollten dies sehen, wenn Sie keine @Test- Methode für Ihre Methoden verwenden, aber sobald Sie dies tun (wie in Ihrem obigen Beispiel mit dataProvider), wird das Attribut enabled überschrieben und seine Standardeinstellung ist wahr, daher das Verhalten, das Sie sehen.

Macht das Sinn?

Ja, danke Cedric.

Ich gehe falsch davon aus, dass die Annotation @test(enabled=false) für die Klasse die Klasse vollständig von der Ausführung ausschließt

Ich stimme zu, dass es ein bisschen kontraintuitiv ist, aber es ist leider zu spät, um es jetzt zu ändern ...

Hallo Cedric!
Wie wäre es, wenn Sie der Annotation hinzufügen und ihn so etwas wie "enabledClass" nennen und ihn standardmäßig auf "true" setzen? Es sollte nur auf Klassenebene (enabledClass = false) verwendet werden, um die gesamte Klasse unabhängig von den Annotationen auf Methodenebene zu deaktivieren und ignoriert zu werden, wenn es für die Methode hinzugefügt wird.
Auf diese Weise würden wir die Abwärtskompatibilität bewahren und gleichzeitig eine ziemlich nützliche Funktionalität bereitstellen.
Wenn Sie möchten, kann ich es selbst implementieren und einen Pull-Request bereitstellen.
Danke im Voraus!

@andronix83 ,

Ich fürchte, das macht die Sache jetzt noch verwirrender, da Sie den feinen Unterschied zwischen enabled und enabledClass erklären müssen.

Das aktuelle Verhalten von enabled ist nicht das intuitivste, aber es scheint im Allgemeinen kein Problem zu sein, wenn ich betrachte, wie oft dieses Problem angesprochen wurde (kaum jemals).

Hallo Cédric,

Ich bin tatsächlich erst letzte Woche auf dieses Problem gestoßen. Ich arbeite an einem Webserver, der auf der Facebook Graph API basiert. Ich hatte eine Testklasse mit einigen Testmethoden, die auf Code angewiesen waren, der auf die Graph-API trifft, während andere Testmethoden überhaupt nicht auf diesen Dienst angewiesen waren. Dann gab es auf Facebook insgesamt für mehr als eine Stunde einen weltweiten Ausfall. Dies führte dazu, dass einige der Tests in dieser Klasse fehlschlugen.

Um den Rest meines Entwicklungsteams frei von Blockaden zu halten, hatte ich gehofft, alle Tests dieser Klasse sofort über eine @Test(enabled=false)-Annotation auf Klassenebene zu deaktivieren. Das hat natürlich nicht funktioniert. Stattdessen musste ich jede fehlgeschlagene Testmethode einzeln deaktivieren, was mehr Zeit kostete als gewünscht oder sogar notwendig war, um dieses Problem zu lösen.

Im Idealfall unterstützt TestNG eine Art von Funktionalität ähnlich der @Ignore- Annotation von JUnit: http://junit.sourceforge.net/javadoc/org/junit/Ignore.html. Lange Rede, kurzer Sinn, Entwickler wünschen sich diese Funktionalität in der Tat.

Dankeschön.

@ecbrodie Dies wird bereits unterstützt (versuchen Sie es!), aber es gibt einen Vorbehalt: Jede einzelne Methode mit einer @Test Anmerkung aktiviert den Test erneut.

@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!
}

Dies liegt an der Semantik, die Attribute auf Methodenebene die auf Klassenebene definierten Attribute überschreiben, so dass die @Test Annotation auf Methodenebene im Grunde genommen @Test(enabled = true) sagt, da dies der Standardwert ist ...

Macht Sinn?

Hallo @cbeust , danke für dieses Beispiel, aber das war schon das Verständnis des Problems, daher denke ich, du hast mich vielleicht falsch verstanden. Dieser Punkt, den ich zu erreichen versuchte, war angesichts der aktuellen Semantik von @Test(enabled=true/false) und dem Wunsch, eine Möglichkeit zu haben, tatsächlich eine Überschreibung von aktiviert auf Klassenebene anzugeben, um alles zu ignorieren, was in der Methode festgelegt ist Ebene, vielleicht ist es an der Zeit, Ihre Haltung gegen das Hinzufügen von enabledClass Anmerkungswerten zu überdenken.

Sie scheinen den ursprünglichen Ansatz, den Sie mit der @Test(enabled)-Semantik verfolgt haben, zu verachten. Wenn dies tatsächlich der Fall ist, warum bringen Sie dann seine Semantik nicht in etwas, das Ihrer Meinung nach intuitiver ist?

Zugegeben, ich denke, ein @Test(enabledClass = false) wäre sinnvoll und es ist die einzige Möglichkeit, Ihren Vorschlag zu implementieren, ohne die Abwärtskompatibilität zu beeinträchtigen. Sollte auch ziemlich einfach sein.

Vielleicht haben Sie oder @juherr Interesse an einer PR?

Mir geht es nicht gut. Ich mag die Idee nicht, ein neues Attribut hinzuzufügen, das nur für die Klasse verwendet wird.
Dann denke ich, dass enable=false eine schlechte Methode ist, wenn sie in Quellen verwendet wird, da Sie die Quellen ändern müssen, wenn Sie die Tests ausführen möchten.
IMO, wenn Sie eine Klasse abwählen möchten, sollte stattdessen testng.xml verwendet werden.
@ecbrodie Wie führen Sie Ihre Tests durch?

Übrigens, ich schlage stattdessen vor, eine IAnnotationTransformer Implementierung bereitzustellen, die das Standardverhalten von enable=false für die Klasse überschreibt.
IAnnotationTransformer hat nur bis zu enable=false alle Tests, wenn ihre Klasse enable=false .
Es wird die Abwärtskompatibilität nicht beeinträchtigen und keinen bestimmten Parameter hinzufügen.
@cbeust Was denkst du?

@juherr Coole PR, es ist in der Tat sehr einfach, mit einem IAnnotationTransformer zu tun.

Meine einzige Sorge ist, dass es für den Benutzer etwas geheimnisvoller ist als ein enabledClass Attribut.

Beachten Sie, dass wir bereits einige Attribute haben, die nur auf Klassenebene anwendbar sind ( suiteName , testName ).

Wie gesagt, der Anwendungsfall gefällt mir nicht. Und ich denke, es wird für die einzigen 2 Personen reichen, die in den letzten 4 Jahren danach gefragt haben :)

@juherr Fair genug.

@ecbrodie Was hältst du von der PR?

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

@cbeust
Nur neugierig. Was wäre, wenn wir einen eingebauten AnnotationTransformer bereitstellen würden, der dies kann?

Ja, es ist, was #816 vorschlägt

@juherr
Danke für das Teilen dieser PR-Informationen. Gibt es einen Grund, warum dies darauf wartet, zusammengeführt zu werden?

Was ist, wenn ich ein Szenario wie folgt habe:

@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. Gehören TC_1 und TC_2 sowohl zur Regressions- als auch zur Rauchgruppe?
2. Werden sowohl TC_1 als auch TC_2 von der Gruppe "Erstellung" abhängen?
3. Wird TC_2 sowohl von der Gruppe "Erstellung" als auch von TC_1 oder nur von TC_1 abhängig sein?

@ Rameshwar-Juptimath Welche Beziehung besteht zwischen Ihrer Stichprobe und diesem Problem?

Aufgrund dieses nicht intuitiven Verhaltens von @Test auf Klassen- und Methodenebene.
Was ist als Best Practice zu empfehlen?
Sollten wir vermeiden, beides in Tests zu verwenden?
Da wir es mehr oder weniger auf Methodenebene verwenden, um für jeden Fall unterschiedliche Datenprovider zu haben, sollten wir es vermeiden, es in der Klasse zu haben?
Die Gedanken?

@aliciatang Das Verhalten ist für alle Annotationsattribute gleich: Werte in der Methode überschreiben die Werte in der Klasse.

Seit 6.13 können Sie @Ignore was das von Ihnen erwartete Verhalten ist. Dokumentation für @Ignore finden Sie hier