Unittests für DB-Zugriffe

[Uwe Raabe]

Zitat von JasonDX:

Wenn ich Tests habe, die bei jeder Codeänderung laufen müssen, und dafür 2 Stunden brauchen weil sie ein externes System ankarren, dann sind diese Tests eine unnötige Behinderung für den Entwickler.
Integrationstests sind wichtig, und genau diese sollten die Schnittstelle zwischen DB und Logik testen. Diese Schnittstelle wird aber in Unittests rausgemockt - damit man seinen Code ändern kann, ohne die Integrationstests laufen lassen zu müssen.

Das Problem mit der Laufzeit gilt aber auch für reine Unittests (z.B. Berechne alle Primzahlen von 1..n mit n ausreichend groß). Deswegen lässt man solche Tests ja auch nicht ständig mitlaufen. Ich bin mir nur nicht sicher, ob die Definition eines Unittests von der Laufzeit abhängt. Oder gibt es irgendwo eine Definition, die Unittests generell als kurz (was auch immer das sein mag) festlegt?

Es ist natürlich schon sinnvoll, kurze Tests spätestens beim Commit oder sogar "ständig" laufen zu lassen (Stichwort TestInsight) und längere Tests dem CI-System zu überlassen. Wie man diese Tests dann im einzelnen nennt, spielt eigentlich eine untergeordnete Rolle.

Was mich bei einem solchen DB-Test eher stören würde, ist die schlechte Portierbarkeit wenn er Zugriff auf einen DB-Server mit einer definierten Datenbank haben muss. Was ist wenn der DB-Server nicht erreichbar ist? Wenn keine (passenden) DB-Treiber installiert sind? Wenn gleichzeitig ein anderer Prozess diese Datenbank manipuliert?

Man muss auch sehen, was eigentlich getestet werden soll. Geht es vielleicht nur darum, ob die richtige SQL-Anweisung erzeugt wird? Das ließe sich natürlich auch ohne DB validieren.