Wie gefährlich sind SetUp und TearDown in NUnit?

Standard

Im klassischen JUnit wurde eine bestimmte Konstellation aus Testobjekten Test-Fixture genannt. Es besteht zumindest aus einem Objekt der getesteten Klasse, aber auch aus Objekten, von denen das getestete Objekt abhängt. Außerdem können auch alle anderen Vorbedingungen, die für den Test notwendig sind, wie z.B. Dateien dazugezählt werden.

Im Buch “xUnit Test Patterns” von Gerard Meszaros werden mehrere Varianten für die Organisation der Testfallklassen erwähnt:

  • Testfallklasse pro Klasse:
    Dabei wird für jede getestete Klasse eine eigene Testfallklasse erstellt.
  • Testfallklasse pro Feature:
    Alle Testmethoden, die ein bestimmtes Feature einer Klasse testen, werden in einer Testfallklasse zusammengefasst. Als Feature werden alle Methoden und Eigenschaften bezeichnet, die zusammen eine Fähigkeit der getesteten Klasse implementieren.
  • Testfallklasse pro Fixture:
    Alle Testmethoden, die das gleiche Testfixture benötigen, werden in einer Testfallklasse zusammengefasst.

In NUnit werden Testfallklassen mit dem Attribut TestFixture markiert. Damit wird angenommen, dass die Testfallklassen nach Fixtures organisiert sind. Häufig werden Testfallklassen auch nach Klassen organisiert. Wenn der Testautor dann Setup-Methoden verwendet, um den Code, der die Testobjekte erstellt, in eine Methode auszulagern, läuft er in die Probleme, die zwei Entwickler von xUnit.net, James Newkirk und Brad Wilson, in ihren Blogs beschreiben:

  • Schwer zu verstehender Code, weil der Setup- und der Cleanup-Code vom eigentlichen Testcode getrennt wird.
  • Im Setup-Code werden mehr Objekte erzeugt, als für die einzelnen Tests notwendig sind. Das kann die Lesbarkeit und die Performance negativ beeinflussen.
  • In Setup-Methoden werden Instanzvariablen initialisiert. Wenn man nicht aufpasst, werden Testobjekte nicht aufgeräumt und können dadurch andere Testfälle beeinflussen.

Als Alternative können Testobjekte durch Methoden erzeugt oder das Pattern Testdata-Builder verwendet werden. Doch auch hier gilt, dass u.U. Testobjekte wieder aufgeräumt werden müssen, z.B. wenn sie Dateien geöffnet haben. Der nächste Test schlägt dann fehl, wenn er die gleiche Datei öffnen will.

Wenn Sie Testfallklassen nach Fixture organisieren, können Sie auch Setup- und Teardown-Methoden verwenden. Es werden dann immer genau jene Objekte erzeugt, die für die Tests notwendig sind, und der Code sollte dennoch lesbar bleiben, weil ja alle Testmethoden auf dem gleichen Fixture aufbauen.

Leave a Reply

Your email address will not be published. Required fields are marked *