dbHero – stop waiting for SQL Server

Well finally, those guys from the code Hero team came up with a tool, which puts an end to those nerv wracking procedures when it comes to taking a snapshot from a database and put it back in.

Imagine, you’re a tester or business analyst or project manager or developer or …. whatever ;)

Today, your task is it, to do some test on a large 3-tier web based system. Some of those tables in the database have millions of records in them. The whole application is quite complex, and well, you start testing the new functionality, the guys from the dev team just added.

Well, you do your tests, find some bugs (surprise, surprise ;) ) circle back to the developers and they fix them (even more surprise ;) ).

So, next day, you do your testing again. Well, you’ld like to BUT, since your tests, influenced the data of the system, some of your tests hit a different scenario. And maybe, your testing doesn’t trigger the buggy behavior anymore, or maybe, the bugs have been fixed. The point is, you don’t know for sure, as your starting point in the test system was a different than the day before…

So you need to take a snapshot of  some of those tables in the database before you start testing, and put it back in afterwards. That gives you exactly the same starting point for any consecutive tests.

Yes, MAYBE you can do this – but not if you’re talking about massive datasets like thousands of records, or ten housands, or hundret thousends… well, you get my point ;)

Using SQL insert scripts, will bring the Enterprise Manager to a halt (if not a crash) if you use tables with more than some ten thousands of records (and maybe you have a couple of those tables in your database and in that script).

The only way, you can use that SQL Insert script is to manually truncate it into smaller chunks, so the Enterprise Manager can work with it. That’s gonna take you ages – and may lead to some mistakes. Even if the Enterprise Manager swallows the whole script in one piece, it’s very, very slow.

The code Hero guys, where annoid about this, in their day to day work and created dbHero. That tool creates either SQL Inserts from SQL Server databases (no, we don’t want to use them), AND so called POWER scripts ;) The POWER scripts are an enhanced way of bulk copy scripts. They are damn fast – (code Hero says more than 50 times faster). Enhanced, why ? Well, also the standard bulk copy has got some issues ;) ) The code Hero guys, don’t reveal all of them (wonder why … ;) ) but point into the direction of encoding schemas, delimiters and string problems, among a few others…. At the same time, they even improved the already good speed of the bulk copy scripts.

Anyhow. Using dbHero makes taking those snapshots in POWER script modus a breath of fresh air ;) Instead of waiting hours or sometimes forever (when Enterprise Manager decides to go dark on you with too larg scripts ;) ), the job is done in seconds to minutes.

That saves time – and yes, you know what I’m gonna say – money ;)

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

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