Wie erzwinge ich, dass der statische Block in jeder Testmethode ausgeführt wird?

8

Ich habe festgestellt, dass der statische Block nur einmal ausgeführt wird, wenn ich mehrere JUnit-Tests ausführe. Wie kann ich die Ausführung für jede Testmethode erzwingen? Ich verwende die neueste Version von JUnit 4.8.2

Nach dem xUnit-Konstruktionsprinzip sollte jede Methode vollkommen unabhängig von anderen sein. Warum statische Blöcke nur einmal ausgeführt werden?

%Vor%

Dies tritt sogar auf, wenn TestMethod1 und TestMethod2 in den verschiedenen Testklassen enthalten sind.

    
user705414 25.04.2011, 23:09
quelle

4 Antworten

10

statische Blöcke werden nur beim Laden von Klassen ausgeführt, weil sie das sind: Klasseninitialisierer. Um einen statischen Block mehrere Male ausführen zu lassen, müssten Sie die Klasse entladen (keine leichte Aufgabe ...).

Wenn Sie statische Blöcke verwenden müssen, können Sie sie testen. Warum nicht den Block in eine öffentliche (statische) Methode auspacken? Alles, was Sie in dieser Welt tun müssen, ist die Methode zu testen:

%Vor%

Sie könnten auch mit nur einem gewöhnlichen Initialisierer davonkommen

%Vor%

Obwohl die Wahrheit ist, dass der meiste Code überhaupt keine Initialisierer verwenden muss.

Bearbeiten: Stellt sich heraus, dass Oracle den statischen Methodenansatz Ссылка

mag     
Philip JF 25.04.2011, 23:29
quelle
4
  

Warum wird der statische Block nur einmal ausgeführt?

Weil das der ganze Punkt der statischen Initialisierungsblöcke ist!

Um es anders auszudrücken: Wenn Sie möchten, dass ein Initialisierungscode mehrmals ausgeführt wird, fügen Sie ihn in einen regulären Konstruktor oder eine Methode oder (in wenigen Fällen) in einen nicht statischen Initialisierungsblock ein.

Im Kontext von JUnit der normale Weg, Teststart- und -abschaltcode mit den Methoden setUp() und tearDown() zu implementieren.

Wenn Sie versuchen, die Ausführung der statischen Initialisierung in Ihrem eigenen Code zu testen, sind Sie auf einem holprigen Weg, denke ich. Aber das Komponententesten von Code mit statischem Zustand (z. B. Singletons) ist immer schwierig ... und das ist einer der Gründe, warum Leute denken, dass der statische Zustand eine schlechte Idee ist.

  • Erwägen Sie die Verwendung eines Dependency-Injection-Frameworks (Inversion of Control) anstelle von Singletons.

  • Alternativ können Sie Ihren Singletons / statischen Initialisierungscode ändern, um den Test zu vereinfachen. Fügen Sie beispielsweise eine statische Methode hinzu, die es einem Test ermöglicht, die Initialisierung erneut auszuführen. (Und bevor Sie sagen, dass dies das Singleton-Muster bricht: Ja, ich weiß. Sie müssen zwischen Design / Implementierung "Reinheit" und Leichtigkeit des Testens wählen.)

Stephen C 25.04.2011 23:23
quelle
0

Ist der statische Code für die Tests der zu testenden Klasse?

Wenn der Code statisch ist und die Tests freigegeben werden können, müssen Sie den Code in eine eigene Klasse verschieben. Dann muss entweder der Testklassenkonstruktor eine statische Instanz instanziieren oder eine Testsuite erstellen, die dasselbe tut.

Wenn Sie möchten, dass jeder Test einzeln steht, dann verschieben Sie, was Sie in Ihrem statischen Block tun, in die setup () / teardown () -Methoden, für die sie da sind.

    
Kelly S. French 25.04.2011 23:50
quelle
-3

Ähm ... mach es nicht-statisch ? Sie können auch Instanzeninitialisierungsblöcke haben (wie statische Blöcke, nur ohne das Schlüsselwort static ). Der Test-Setup-Code sollte jedoch tatsächlich in eine explizite Methode setUp() oder @Before gehen.

    
Michael Borgwardt 25.04.2011 23:13
quelle

Tags und Links