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?
AFAIK gibt es keine definierte, sondern höchstens eine implizierte Zeitbeschränkung. Ich lebe mit forcierten Zeitlimit auf
Unit-Tests, um deren Charakter beizubehalten. Die Option, Ausnahmefälle zu bestimmen existiert, dafür gelten dann aber wieder Auflagen.
Beim Beispiel der Primzahlen macht es u.U. Sinn, einen Test zu haben, der länger braucht - allerdings darf der dann nur laufen, wenn auch der Code zur Primzahlenberechnung geändert wird.
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.
Bei mir laufen ALLE Unittests die durch den Code beeinflusst werden beim Commit; Wenn Schnittstellen zu anderen Systemen geändert werden, laufen die entsprechenden Tests auch mit. Das liegt aber an der Größe der Codebase der Aktivität darauf.
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?
Deswegen sollte man eine Schnittstelle haben, die man durch einen Mock ersetzen kann. Wird die Schnittstelle (die auch der einzige Ort sein sollte, in dem
DB-spezifische Queries generiert werden) geändert, müssen diese Tests mit
DB-Anbindung laufen. Für alles andere nimmt man Mocks, die das Verhalten der Schnittstelle simulieren.
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.
Ja, wobei man auch wieder verifizieren muss: Was ist die richtige
SQL-Anweisung?