Best Practice: Data Driven Test

[mh166]

Hallo,

ich muss mal wieder mit einer Grundsatzfrage stören. Ich habe in meinen Tests eine Funktion, die XML-Daten lädt und diese dann weiter verarbeitet. Jetzt sollen dafür aber verschiedene Inputs getestet werden, um möglichst alle Varianten zu testen.

Mal drei Beispiele:

Code:

1) Falsches Root-Element
========================
<wrongRoot />

2) Nur Eltern-Element enthalten
===============================
<correctRoot />

3) Inklusive Kind-Elemente
==========================
<correctRoot>
  <childOne />
  <childTwo />
</correctRoot>

Das sind jetzt kurz sehr simple Beispiele, die in der Praxis natürlich deutlich umfangreicher gestaltet sind.

Nun die Frage: wie stelle ich das am Besten in meinen Tests dar? Zur Info: ich nutze DUnitX als Test-Framework.

Einerseits könnte ich jetzt allesamt in den Test-Klassen hardcoden. Außerdem gibts das [TestCase(parameters)] Attribut. Doch dort den XML-String rein zu fädeln ist unhübsch.

Am liebsten wäre mir ja eine Möglichkeit die Daten in ein eigenes Verzeichnis zu stecken und dann dynamisch für jede Datei dort die Daten zu laden und den Test auszuführen.

Da ich aber noch ganz am Anfang meiner Unit-Test-"Karriere" stehe, möchte ich gern wieder eure Meinung dazu hören: wie löst mans am sinnvollsten? Oder verfehle ich hier wömöglich mal wieder den Zweck von Unit-Tests? (Ich hoffe nicht... )

[JasonDX]

Normalerweise hat man die Daten, die für Tests benötigt werden, in den Testklassen selbst. Im Endeffekt sind einfache Strings, die als Parameter für die testenden Methoden gelten, auch nix anderes als Testdaten.
Wenn diese Daten zu groß oder umständlich sind, in eine Unit zu stecken (oder wenn sie die Lesbarkeit dieser arg beeinträchtigen) spricht nichts dagegen, diese aus anderen Resourcen, bspw. Dateien zu lesen.

In pseudocode würde dann das bspw. so aussehn:

Code:

const WRONG_ROOT_DATA_FILE = './wrongRoot.xml';
const CORRECT_ROOT_DATA_FILE = './correctRoot.xml';
const CORRECT_ROOT_WITH_CHILDREN_DATA_FILE = './correctRootWithChildren.xml';

[Data] loadXmlDataFromFile(path) { sehr, sehr, sehr einfacher Code zum laden einer Datei }

test_processTree_wrongRoot()
  data = loadXmlDataFromFile(WRONG_ROOT_DATA_FILE);
  // Test mit den daten

test_processTree_correctRoot()
  data = loadXmlDataFromFile(CORRECT_ROOT_DATA_FILE);
  // Test mit den daten

Ich würde aber empfehlen, das Laden und Verarbeiten zu trennen. Zum einen ist es dann einfacher Testbar, zum anderen kannst du dann bspw. das Laden auch woanders verwenden, oder solltest du die Daten mal anders laden wollen, wäre das dann auch kein Problem

[Uwe Raabe]

Ich habe da mal vor einiger Zeit was dazu geschrieben. Allerdings kann ich nicht sagen, ob das auch unter DUnitX so noch funktioniert.

[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.