TADOQuery von Hand füllen (ohne Datenbankanbindung)

[apm]

Moin!

Ich versuche mich gerade mal intensiver mit Unit-Tests zu beschäftigen von ner DB-Anwendung.
Wenn ich Testfälle schreibe die mit Daten von ner DB arbeiten, habe ich mehr oder weniger das Problem, dass sich das Ergebnis durch die Daten in ihr ändern kann.
Kann ich eine Query direkt per Hand füllen, damit das Ergebnis immer identisch ist?

Oder hat jemand eine andere Idee wie man DB-Funktionen automatisiert testen kann?

Gruß apm

[Schokohase]

Wenn du mit einem

Delphi-Quellcode:

TDataSet

arbeitest, dann kannst du auch ein

Delphi-Quellcode:

TClientDataSet

anbieten.

Wenn du allerdings ein

Delphi-Quellcode:

TADOQuery

benötigst, dann ist deine Klasse nicht so wirklich gut testbar.

[apm]

Die ganze Anwendung arbeitet mit TADOQuery.
Da was umzuschreiben mit anderen Komponenten wär schon harter aufwand - wenn ein einfaches Refactoring nicht klappt.

Sonst mach ich ne Test-DB mit readonly auf dem User. Dann kann ich zumin die Datenverarbeitung / -ausgabe save damit Testen.

[Der schöne Günther]

Deine Query hat doch eine Connection. Gib ihr eine Connection die eine Memory-Table mit dem Namen hat welche deine Query erwartet.

Ich habe auch ein bisschen gebraucht um das in einer Anwendung komplett durchzuziehen bis der gesamte Datenbank-Kram komplett testbar war, aber ich denke es hat sich gelohnt...

Wenn du z.B. Connection und Queries und alles auf einem Datenmodul hast dann müsste man das natürlich erst einmal trennen. Der Gewinn ist dann natürlich dass es der Logik mit den Queries und allem dann auch reichlich egal ist ob es von einem MS-SQL-Server, SQLite, Memory-Tables oder sonstwas kommt...

[apm]

Ok! Da hab ich ja schon mal nen Ansatz zum weiter schauen und stöbern.
Hast du dazu nen nützlichen Link?


Ich schau grad was Die TADOQuerys noch so können. Hätte ich auch mal früüner machen können ...
Aber ist SaveToFile() / LoadFromFile() nich auch ne Lösung?

EDIT: Son Kindergartentest schaut nicht schlecht aus. Also das ich mir einfach mal ne Sicherung von allen Zuständen mache und die dann im Test lade um zu bewerten das das iO was passiert.

[hoika]

Hallo,

Zitat:

Sonst mach ich ne Test-DB mit readonly auf dem User. Dann kann ich zumin die Datenverarbeitung / -ausgabe save damit Testen.

Bei Datenbankzugriffs-Tests musst Du doch eh Test-Datenbanken benutzen.

[p80286]

Zitat:

Zitat von hoika (Beitrag 1427280)

Hallo,

Zitat:

Sonst mach ich ne Test-DB mit readonly auf dem User. Dann kann ich zumin die Datenverarbeitung / -ausgabe save damit Testen.

Bei Datenbankzugriffs-Tests musst Du doch eh Test-Datenbanken benutzen.

Muß man nicht, sollte man aber.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1427281)

Zitat:

Zitat von hoika (Beitrag 1427280)

Bei Datenbankzugriffs-Tests musst Du doch eh Test-Datenbanken benutzen.

Muß man nicht, sollte man aber.

Genau, die können sogar separate Tabellen mit Soll Ist Werten enthalten.

Beispiel
Wenn man einen definierten Ablauf hat, das einmal durchspielt, das Ergebnis einfriert (in eigener Tabelle), dann:
Ist es ziemlich einfach, nach neuen Läufen das neue Resultat mit dem eingefrorenen Ergebnis zu vergleichen.
sowas wie
select * from TabelleA minus Select * from TabelleB

Man kann natürlich auch Datenmengen separat abspeichern, aber was mach ich dann damit? Mit dem Hexeditor anschauen? Mit einem Textdiff?
SQL ist dafür geschaffen.

[TigerLilly]

Eigentlich sollte ein Unit-Test in Isolation sein, also eben keine Abhängigkeiten haben, sonst testest du ja mehrere Sachen auf einmal.

Sonst ist eine Test-Datenbank mit definiertem Inhalt das geeignetste. Die Datenbank kann ja an den passenden Stellen leer sein + dein Test füllt sie an diesen Stellen mit definierten Testdaten.