Unittests für DB-Zugriffe

[hoika]

Hallo,
Integrationstest, äh, eher nein.

Genauer gesagt, mische ich das meistens

Im Moment versuche ich gerade, wirklich einen Einzeltest,
also eine einzige Query (OK, ist eine Service-Methode, der die Query über Filterkriterien zusammenbaut), zu testen.
Dazu will ich konstante Testbedingungen, habe also eine DB mit einem bestimmten Aufbau und Inhalt
und kann meinen Service mit beliebigen Filterkriterien testen.

Ist also doch ein Unittest.

Man merkt es aber schon, wenn dieser Zeitcase mitläuft, dauert es eine Weile (DB-Connect),
verglichen mit einem Nicht-DB-Testcase.


Heiko

[Bernhard Geyer]

WEnn du Unittests mit z.B. Jenkins nach jedem Checkin laufen lässt, so lasse die DB-Unittest z.B. nur alle Tage laufen wenn sonst die Laufzeit zu hoch wäre.

[Uwe Raabe]

Kannst du für den DB-Test nicht eine In-Memory-Datenbank nehmen (z.B. FireDAC MemTables mit LocalSQL) oder wenigstens eine Embedded-Lösung? Dann kannst du die Datenbank direkt im Test-Setup aufbauen. Das ist leichter zu pflegen wenn sich mal was an der Logik oder am Test ändert.

[hoika]

Hallo,

es geht mir gerade um das "Mach es so, wie es beim Kunden läuft?".
Aber mit einer Embedded-DB ist eine gute Idee.

Ich denke, ich mache eine Extra-DB-Suite als Wrapper und packe dort meine DB-TestCases rein,
dann kann ich die global aus- und einknippsen.

Danke


Heiko

[Dejan Vu]

Ein Unittest mit DB-Zugriff geht über Systemgrenzen hinweg und ist somit kein Unittest. Soviel erst einmal zur Definition.

Ändert natürlich nichts an der Tatsache, das Du den DB-Zugriff testen. Was willst du denn testen? Ob eine Query das erwartete Ergebnis liefert? Ob Tabellen vorhanden sind? Ob die DB vorhanden ist?
Was ist denn bei einer Query das erwartete Ergebnis? Müsste die Datenbank nicht immer die gleiche sein, wenn Du die Tests neu startest?

Fragen über Fragen.

Also, erklär mal, was Du genau willst.

[Sir Rufo]

@Dejan Vu

Deine Fragen sind vom TE eigentlich schon beantwortet worden ... (siehe #3)

[Stevie]

Zitat von hoika:

... DB ...

Ist also doch ein Unittest.

Zitat von Dejan Vu:

Ein Unittest mit DB-Zugriff geht über Systemgrenzen hinweg und ist somit kein Unittest. Soviel erst einmal zur Definition.

Exakt. Ein Unittest ist per Definition isoliert.

Zitat von Wikipedia:

Modultests testen ein Modul isoliert, d. h. weitgehend ohne Interaktion mit anderen Modulen. Deshalb müssen oder können bei Modultests andere Module beziehungsweise externe Komponenten wie etwa eine Datenbank, Dateien, Backendsysteme oder Unterprogramme durch Hilfsobjekte simuliert werden, soweit das zu testende Modul (Prüfling oder Testobjekt) diese benötigt. Vollständige Tests mit allen Komponenten in ihrer Originalversion sollten in den nachfolgenden Integrations- und Systemtests durchgeführt werden.

[hoika]

Hallo,
dann ist das halt kein Unittest
Ich will ja gerade den DB-Zugriff selbst testen.
Dahinter kommen in anderen Methoden des Testcases noch die eigentlichen Detailtssts.

Und ja, genau dafür baue ich mir eine DB, die genau die Tabellen und Inhalte hat, die ich für meinen Test erwarte.
Zusätzlich enthält diese DB natürlich noch andere Daten, die beim Where der SQL-Abfeage ausgefiltert werden.

Danke

Heiko

[Dejan Vu]

Du willst hier also den DB-Zugriff und die Query testen? Oder deinen dynamischen Querybuilder?

Was willst Du am Zugriff testen? Das ADO funktioniert und du den Connectionstring richtig geschrieben hast? Nun ja, das geht auch im einem einfachen Vergleich.

Den Querybuilder kannst du durch einfache Unittests testen. Für jede Option ein Test. Ist das zu kompliziert? In kleinere Klassen aufteilen.

Stimmen die Feldnamen der erzeugten Query mit den aktuellen Tabellennamen überein? Dann kannst du die Query einfach gegen die DB laufen lassen. Das ist zwar kein UT, stellt aber trotzdem sicher, das die Query ausführbar ist. Allerdings: Welche Query? Alle möglichen? Eine, von der Du meinst, das sie alle Feldnamen enthält? Wie stellst Du das sicher?

Dann lieber die Feldnamen direkt verifizieren, d.h. banale UT für die Felder schreiben. Bekommt der QB die Feldnamen per Schema aus der DB? Dann teste das.

[Uwe Raabe]

Zitat von hoika:

dann ist das halt kein Unittest

Da hast du vollkommen Recht! Es Nicht-Unittest ist allemal besser als gar kein Test. Solange er das testet was du willst, kann dir eigentlich egal sein, ob es formell ein Unittest ist oder nicht. Ob er dann zusammen mit den anderen (echten) Unittests ausgeführt wird oder separat ist auch völlig Banane, solange er eben auch ausgeführt wird.

Ich habe auch bestimmt eine große Zahl an Tests unter der Rubrik "Unittests" laufen, die streng genommen gar keine sind. Trotzdem erfüllen sie ihren Zweck und ich möchte nicht mehr darauf verzichten. In manchen gewachsenen Projekten ist das manchmal die einzige Möglichkeit, eine brauchbare Testabdeckung herzustellen. Wenn man dafür dann die Infrastruktur der Unittests (z.B. DUnit) nutzt, ist das auch nicht mehr als Pragmatismus. Mögen die Dogmatiker hier jetzt auch hyperventilieren - das geht mir vollkommen am end. vorbei