Best Practice: Data Driven Test

[Dejan Vu]

Streng genommen ist es kein Unittest, wenn I/O verwendet wird. Es ist irgendwas. Und es testet. Aber eben kein Unittest. Einfach deshalb, weil das Verändern der Dateien deinen Test zerschießt.

Es ist vollkommen legitim, die Testdaten im Test selbst als Konstante zu deklarieren.

Ähnliches gilt z.B. auch für stored procedures. Es liegt nahe, in seinem DUnit-Framework auch Tests für die SP zu schreiben. Aber das sollte man nicht tun, weil Systemgrenzen überschrieben werden.

[JasonDX]

Zitat von Dejan Vu:

Streng genommen ist es kein Unittest, wenn I/O verwendet wird. Es ist irgendwas. Und es testet. Aber eben kein Unittest. Einfach deshalb, weil das Verändern der Dateien deinen Test zerschießt.

Der UnitTest kann gern IO verwenden. Für die zu testende Klasse sollten diese Operationen gemockt werden.
Was das Verändern von Testdaten betrifft: Das zerschießt jeden Test - unabhängig davon, ob das jetzt einkompilierte Dateien, Resourcen oder im Code definierte Konstanten sind.

[Stevie]

Zitat von Dejan Vu:

Es liegt nahe, in seinem DUnit-Framework auch Tests für die SP zu schreiben. Aber das sollte man nicht tun, weil Systemgrenzen überschrieben werden.

Wenn du die Aussage zu "in seinen Unittests sollte man nicht ..." umformulierst, stimme ich dir zu. Ansonsten kann ich nur sagen, DUnit verbietet nicht, damit Integrationtests zu schreiben, es funktioniert sogar hervorragend.