Leider ist mir dieses Testverfahren sehr häufig in bestehenden Projekten unterkommen, weshalb ich es hier aufführe. Die Daten einer Entwicklungsumgebung unterliegen ständigen Veränderungen, nicht nur durch Tests sondern auch durch Weiterentwicklungen, Migrationen, etc. Als Konsequenz muss man damit rechnen, dass die Test sehr häufig fehlgeschlagen. Ja sogar der Datenbestand für die Weiterentwicklung betroffen ist und unbrauchbar werden kann.

Testablauf am Beispiel der Referenzanwendung

1. Verbindung zur Entwicklungsdatenbank wird geöffnet.
2. Es wird davon ausgegangen dass die Daten in der Tabelle [dbo].[Source] zum 1.1.2014 vorliegen.
3. Die Tabelle [dbo].[Target_Sum] wird gelöscht.
   • [dbo].[Delete_Target_Sum_ByCalcDate]
4. Die Tabelle [dbo].[Target_Sum] wird befüllt.
   • [dbo].[Insert_Target_ByCalcDate]
5. Es wird geprüft ob die Daten wie erwartet in der Tabelle [dbo].[Target_Sum] vorliegen.
   • Die Daten werden vom Test in eine Datei exportiert.
   • Die Datei wird mit einer erwarteten Datei verglichen.

   1: [TestMethod]

   2: public void DALTest()

   3: {

   4:     DBManagerTarget mgr = new DBManagerTarget();

   5:     DateTime calcDate = new DateTime(2014, 01, 01);

   6:     mgr.DeleteTargetSum(calcDate);

   7:     mgr.FillTarget(calcDate);

   8:  

   9:     DBManager testDatenmanger = new DBManager("DB", false);

  10:  

  11:     string filename = "DALTest_UnitTest1.txt";

  12:     testDatenmanger.ReadToFile(

  13:         DIRTARGET + filename,

  14:         "SELECT * FROM dbo.Target_Sum WHERE CalcDate='2014-01-01';");

  15:  

  16:     CompareHelper.AssertAreEual(DIRSOURCE + filename, DIRTARGET + filename);

  17: }

<connectionStrings>

  <clear/>

  <add name="DB" connectionString="... Initial Catalog=DBTesting; ..."/>

</connectionStrings>

Ergebnis: Erfolgreich

SELECT * FROM dbo.Target_Sum WHERE CalcDate='2014-01-01';

CalcDate(datetime),ID(int),Value(float)

01.01.2014 00:00:00,1,10

01.01.2014 00:00:00,2,20

01.01.2014 00:00:00,3,30

01.01.2014 00:00:00,4,40

Sollte jedoch die Tabelle [dbo].[Target_Code] schon mit anderen Werten befüllt sein, so wären abweichende technische IDs das Ergebnis und der Testfall wäre nicht erfolgreich.

Vorteile

• Geringer Aufwand für das Erstellen von Tests
  • Benötigte Testdaten könnten schon vorliegen
• Aktuellster Softwarestand (Struktur)

Nachteile

• Test schlagen häufiger fehl
  • Hoher Aufwand bei Fehlersuche
  • Entwicklungsdaten unterliegen Änderungen
• Einspielen von Testdaten zerstört ggf. Entwicklungsdaten
  • Referenzierte Daten werden beim Skripten leicht übersehen
  • Nicht alles kann geskriptet werden, siehe IDENTITY Spalte in [dbo].[Target_Code]

Auch wenn dieses Vorgehen sehr fehleranfällig ist, so ist es immer noch besser als keine Testfälle zu haben.

zur Übersicht