In den vielen Projekten schrecken nicht Nachteile der einen oder anderen Lösung ab, sondern alleine der Aufwand. Tests aufzusetzen und zu pflegen kostet Zeit. Leider vergessen die meisten den Aufwand der durch Fehler und deren Suche entsteht.
Sollte es doch Testfälle geben, so werden in sehr vielen Projekten die Tests gegen die Entwicklungs- oder eine separate Testdatenbank ausgeführt. Aber es gibt weitaus elegantere Möglichkeiten seine Anwendung zu testen, als diese beiden.

Ich habe hier drei Grundvorgehen

• Testdaten liegen vor und Änderungen durch Tests werden in der Datenbank persistiert
  • Testfälle in der Entwicklungsdatenbank
  • Testfälle in separater Testdatenbank
• Testdaten liegen als Snapshot vor, der immer wieder neu und sauber verwendet wird
  • Testfälle in zur Laufzeit gemounteter Datenbank
• Testdaten werden in eine immer wieder neu erstellte Datenbank eingespielt
  • Testfälle in zur Laufzeit generierter Datenbank

mit einer Erweiterung

• dem TransactionContext
  • Testfälle mit TransactionContext

kombiniert. Ich bin zwar nur auf die Kombination des TransactionContextes mit der Entwicklungsdatenbank eingegangen, aber genauso sind andere Zusammensetzungen möglich.

• Bereits vorgestellte Möglichkeit
  1. Entwicklungsdatenbank verwenden
  2. TransactionContext  erstellen
  3. Löschen aller unnötigen Daten
  4. Testdaten einspielen
  5. Test durchführen
  6. Ergebnisse prüfen
  7. Rollback durchführen

• Weitere Möglichkeit
  1. Mit Testdaten gefüllte Datenbankdatei oder Testdatenbank verwenden (Snapshot)
  2. TransactionContext  erstellen
  3. Test durchführen
  4. Ergebnisse prüfen
  5. Rollback durchführen

• Weitere Möglichkeit
  1. Einmalig im Test generierte Datenbank oder leere Datenbank verwenden
  2. TransactionContext  erstellen
  3. Testdaten einspielen
  4. Test durchführen
  5. Ergebnisse prüfen
  6. Rollback durchführen

Ich persönlich setzte gern die Variante mit der Entwicklungsdatenbank und TransactionContext ein. Hier finde ich immer den aktuellsten Softwarestand vor, auch wenn das heißt dass hin und wieder Testfälle während der Entwicklung fehlschlagen. Hauptsache sie laufen erfolgreich vor dem Release durch!

Kleine Tipps zur Fehlersuche

Durch den Rollback am Ende des Tests kann man nicht mal eben die Ergebnisdaten in der Datenbank prüfen. Sie werden ja nicht persistiert, deshalb:

• Testfälle sollten “überschaubar” sein, also bitte nicht die halbe Datenbank in zwei Testfällen testen.
• Testfälle sollten niemals auf Ergebnissen andere Testfälle aufbauen, sondern diese benötigten Testdaten beim Start selbst einspielen
• Testfälle sollten so viele Ergebnisse wie möglich rausschreiben, eine Prüfung im Code mit dem Ergebnis “fehlerhaft” ist meist nicht sehr hilfreich
  • Im Beispiel habe ich immer das Resultset der Prüfabfrage herausgeschrieben. Vielleicht hilft manchmal auch das Rausschreiben einer Eingangstabelle weiter.

Zur Analyse des Fehlers können mit etwas Aufwand fast alle Testfälle auch in entsprechende SQL Skripte umgewandelt werden:

BEGIN TRANSACTION

TRUNCATE TABLE [dbo].[Source] 

TRUNCATE TABLE [dbo].[Target_Sum] 

TRUNCATE TABLE [dbo].[Target_Code] 

INSERT INTO [dbo].[Source] ( [CalcDate],[Code],[Value]) VALUES ('2014-01-01','A','10');

...

EXEC [dbo].[Insert_Target_ByCalcDate] '2014-01-01'

SELECT * FROM [dbo].[Source] 

SELECT * FROM [dbo].[Target_Sum] 

SELECT * FROM [dbo].[Target_Code] 

ROLLBACK TRANSACTION

Aber im Endeffekt lässt sich sagen, selbst langsame und von Entwicklungsdaten beeinflusste Tests sind besser als keine. Es reicht sie am Ende der Entwicklung vor dem Release zum Laufen zu bringen.

zur Übersicht