Testen mit Datenbank, ganz ohne Odyssee

Kaum eine Anwendung kommt ohne Daten aus einer Datenbank aus, und kaum ein Entwickler möchte ohne die aufs grüne Lämpchen gehenden Unit-Tests an größeren Projekten arbeiten.
Um Datenbanken und Unit-Tests miteinander verheiraten zu können, gibt es mehrere Ansätze.

Natürlich ist der erste und auch gute Ansatz von Unit-Tests, die Bausteine mit hardcodierten Standard-Daten zu penetrieren, die nicht aus einer Datenbank kommen: schließlich ist das Zusammenspiel mit der Datenbank schon ein großer Schritt in Richtung Integrationstest und gibt zeitgleich auch noch die Möglichkeit zu prüfen, ob die Klassen aus der Datenbankschicht wie erwartet funktionieren. Je mehr Variationen an Daten man dahingehend testen möchte, desto dringender wird es, die Methode der datenbank-getriebenen Tests gegenüber denen mit festverdrahteten Eingabeparametern zu präferieren. Und ganz nebenbei bemerkt: man trennt sich auch weiter von der Gefahr, ausschließlich mit idealisierten Daten zu testen, und nimmt dann doch jene Daten zur Brust, die in einem richtigen user-generierten Einsatz gewonnen wurden, ohne mittelfristig mehr Code für die Tests als die eigentliche Auftragsarbeit zu entwickeln.

Durch Ignorieren des Eventuellen werden Unit-Tests schließlich nach und nach immer weniger wert – insbesondere dann, wenn diese falsch positiv auf grün gehen.

Um diesen Wertverlust zu vermeiden, kann man sich eigentlich nur noch behelfen, in dem man die Datenbank wieder an einen wohldefinierten Ausgangspunkt zurückversetzt, mittels einem Script jene Datensätze erzeugt, die Grundlage für die weitergehenden Tests auf der Datenbank werden sollen und anschließend wieder aufräumt, um die Tests bis zur Reife der Programmierung immer und immer wieder anstoßen zu können. Dies kann man natürlich mit der Hilfe von Transaktionen machen: was allerdings bei vielen aufeinander aufbauenden Tests schnell unübersichtlich werden kann.

Einfacher ist es dann doch, sich den Auszug mit einem Vorher-Stand an Testdaten nebenhin zu legen und diese Daten dann vor den Tests einmalig konsistent zu reimportieren. Bei drei Tabellen mag man vielleicht das ganze noch per Hand pflegen. Aber auch hier schon ist es doch wesentlich einfacher und sicherer, auf einen Knopf zu drücken, der einem die aus dem Einsatz entstandenen Daten aus einer Datenbank zieht und zum immer wieder Einspielen archiviert. Auch aus dieser Motivation heraus entstand dbHero – ein schmuckes Tool, welches bei der täglichen Arbeit bei uns nicht mehr wegzudenken ist. Denn getrost kann man mit real-world Tests ein stückweit grüner auf grün gehen.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • LinkedIn
  • MySpace
  • Netvibes
  • ThisNext
  • TwitThis
  • Yahoo! Buzz
  • MisterWong.DE
  • Webnews.de
  • Blogosphere News

Einen Kommentar schreiben

 

 

 

Diese HTML-Tags können verwendet werden

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>