![]() |
Datenbank: Firebird • Version: 2 • Zugriff über: IBDAC
Unittests für DB-Zugriffe
Hallo,
in einem Dokument zu Unittests habe ich gelesen, dass DB-Zugriffe in Unit-Tests nichts zu suchen haben, weil sie die Testdauer extrem verlangsamen. Nur wie teste ich denn jetzt die Korrektheit meiner DB-Zugriffe ? Sollte man vielleicht 2 Unit-Test-Projekte machen, eines für die DB-Zugriffe und eines für alle anderen? Wie geht ihr denn dabei vor? Danke Heiko |
AW: Unittests für DB-Zugriffe
Zitat:
![]() |
AW: Unittests für DB-Zugriffe
Hallo,
Integrationstest, äh, eher nein. Genauer gesagt, mische ich das meistens ;) Im Moment versuche ich gerade, wirklich einen Einzeltest, also eine einzige Query (OK, ist eine Service-Methode, der die Query über Filterkriterien zusammenbaut), zu testen. Dazu will ich konstante Testbedingungen, habe also eine DB mit einem bestimmten Aufbau und Inhalt und kann meinen Service mit beliebigen Filterkriterien testen. Ist also doch ein Unittest. Man merkt es aber schon, wenn dieser Zeitcase mitläuft, dauert es eine Weile (DB-Connect), verglichen mit einem Nicht-DB-Testcase. Heiko |
AW: Unittests für DB-Zugriffe
WEnn du Unittests mit z.B. Jenkins nach jedem Checkin laufen lässt, so lasse die DB-Unittest z.B. nur alle Tage laufen wenn sonst die Laufzeit zu hoch wäre.
|
AW: Unittests für DB-Zugriffe
Kannst du für den DB-Test nicht eine In-Memory-Datenbank nehmen (z.B. FireDAC MemTables mit LocalSQL) oder wenigstens eine Embedded-Lösung? Dann kannst du die Datenbank direkt im Test-Setup aufbauen. Das ist leichter zu pflegen wenn sich mal was an der Logik oder am Test ändert.
|
AW: Unittests für DB-Zugriffe
Hallo,
es geht mir gerade um das "Mach es so, wie es beim Kunden läuft?". Aber mit einer Embedded-DB ist eine gute Idee. Ich denke, ich mache eine Extra-DB-Suite als Wrapper und packe dort meine DB-TestCases rein, dann kann ich die global aus- und einknippsen. Danke Heiko |
AW: Unittests für DB-Zugriffe
Ein Unittest mit DB-Zugriff geht über Systemgrenzen hinweg und ist somit kein Unittest. Soviel erst einmal zur Definition.
Ändert natürlich nichts an der Tatsache, das Du den DB-Zugriff testen. Was willst du denn testen? Ob eine Query das erwartete Ergebnis liefert? Ob Tabellen vorhanden sind? Ob die DB vorhanden ist? Was ist denn bei einer Query das erwartete Ergebnis? Müsste die Datenbank nicht immer die gleiche sein, wenn Du die Tests neu startest? Fragen über Fragen. Also, erklär mal, was Du genau willst. |
AW: Unittests für DB-Zugriffe
@Dejan Vu
Deine Fragen sind vom TE eigentlich schon beantwortet worden ... (siehe #3) |
AW: Unittests für DB-Zugriffe
Zitat:
Zitat:
Zitat:
|
AW: Unittests für DB-Zugriffe
Hallo,
dann ist das halt kein Unittest :) Ich will ja gerade den DB-Zugriff selbst testen. Dahinter kommen in anderen Methoden des Testcases noch die eigentlichen Detailtssts. Und ja, genau dafür baue ich mir eine DB, die genau die Tabellen und Inhalte hat, die ich für meinen Test erwarte. Zusätzlich enthält diese DB natürlich noch andere Daten, die beim Where der SQL-Abfeage ausgefiltert werden. Danke Heiko |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz