Unittests für DB-Zugriffe

[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:

Zitat von hoika (Beitrag 1305494)

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

Delphi-Quellcode:

end.

vorbei :wink:

[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.

[Uwe Raabe]

Zitat:

Zitat von JasonDX (Beitrag 1305506)

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.

[JasonDX]

Zitat:

Zitat von Uwe Raabe (Beitrag 1305514)

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.

Zitat:

Zitat von Uwe Raabe (Beitrag 1305514)

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.

Zitat:

Zitat von Uwe Raabe (Beitrag 1305514)

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.

Zitat:

Zitat von Uwe Raabe (Beitrag 1305514)

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?

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1305505)

Mögen die Dogmatiker hier jetzt auch hyperventilieren - das geht mir vollkommen am

Delphi-Quellcode:

end.

vorbei :wink:

Das hat nix mit Dogma zu tun, sondern mit genauen Begrifflichkeiten, da einige ständig Unit und Integrationstests (beide gleichermaßen wichtig!) in einen Topf werfen.

[hoika]

Hallo,
nettes Thema habe ich da aufgeworfen:)

Zum Punkt Mock-Objekte:
Wie prüfe ich meine App beim Umstieg auf eine neue FB-Version?

Natürlich ohne die Mocks!

Mir ging es gerade und: Kommt hinten das richtige raus?

Heiko

[Dejan Vu]

Wir haben (so wie jeder, denke ich) das gleiche Problem. Die Frage, die Du dir stellen musst, ist nicht: "Wie teste ich den Code, den ich geschrieben habe?" Sondern eher: "Wie schreibe ich Code, damit ich ihn testen kann?" Bei der DB-Frage würde ich wirklich alle Einzelkomponenten testen (deinen Provider brauchst Du nicht zu testen). Schreibe Dir doch DB-Unittests, die z.B. sicherstellen, das die Tabellen und Views ein bestimmtes Format haben. Auf der anderen Seite schreibst du die UT, die gegen genau dieses Layout prüfen.

Um einen (Blackbox)Integrationstest, der einfach prüft, was hinten rauskommt, kommst Du eh nicht herum. Vielleicht testest Du ja in der DB gegen die Tabelle (A,B,C) und im UT gegen (A,B,X). Beide Tests gelingen.

[BUG]

Zitat:

Zitat von hoika (Beitrag 1305631)

Natürlich ohne die Mocks!

Imho lassen sich die Antworten so zusammenfassen: Das sind Integrationstest. Es empfiehlt sich, sie logisch von den Unit-Test zu trennen, aber es spricht nichts dagegen die gleiche Tool-Unterstützung wie für Unit-Tests zu verwenden.

Zitat:

Zitat von Dejan Vu (Beitrag 1305638)

Die Frage, die Du dir stellen musst, ist nicht: "Wie teste ich den Code, den ich geschrieben habe?" Sondern eher: "Wie schreibe ich Code, damit ich ihn testen kann?"

Die schwierigeren Varianten davon sind: "Wie teste ich den Code, den ich nicht geschrieben habe?" und "Wie schreibe ich Code um, damit ich ihn testen kann?" :stupid:

[hoika]

Hallo,
genau diese Trennung der länger dauernden Tests bin ich am Überlegen.
Ich liege also zumindestens nicht so falsch mit meinem aktuellen Vorgehen.

Danke

Heiko