Unittests für DB-Zugriffe

[hoika]

Hallo,

in einem Dokument zu Unittests habe ich gelesen,
dass DB-Zugriffe in Unit-Tests nichts zu suchen haben, weil sie die Testdauer extrem verlangsamen.

Nur wie teste ich denn jetzt die Korrektheit meiner DB-Zugriffe ?

Sollte man vielleicht 2 Unit-Test-Projekte machen, eines für die DB-Zugriffe und eines für alle anderen?

Wie geht ihr denn dabei vor?


Danke


Heiko

[BUG]

Zitat von hoika:

Nur wie teste ich denn jetzt die Korrektheit meiner DB-Zugriffe ?
Sollte man vielleicht 2 Unit-Test-Projekte machen, eines für die DB-Zugriffe und eines für alle anderen?

Im Prinzip: Nicht alle Test müssen Unit-Test sein. Es gibt vermutlich Teile deines DB-Zugriffes für die Unit-Test sinnvoll sind (zB. Query-Generatoren). Die Interaktion mit der DB sind vielleicht eher was für Intergrationstests.

[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