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.