Testen von Datenbanken – 3 Testfälle in separater Testdatenbank

26. März 2015

Bei diesem Vorgehen werden die Testfälle gegen eine eigene Testdatenbank ausgeführt, die von der Entwicklungsdatenbank losgelöst ist. Diese Umgebung wird dann mit Testdaten befüllt und im Test verwendet.

Dieses Vorgehen trifft man ebenfalls sehr häufig, dabei wird eine zweite zur Entwicklung strukturgleiche Umgebung aufgebaut. Sie muss immer auf dem Stand der Entwicklung gebracht werden! Die Daten werden genau auf die Testfälle zugeschnitten und müssen erst aufgebaut werden. Der Testcode entspricht dabei sogar dem vorherigen Vorgehen.

Testablauf am Beispiel der Referenzanwendung

  1. Verbindung zur Testdatenbank 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.
[TestMethod]

public void DALTest_SeperateDB()

{

    DBManagerTarget mgr = new DBManagerTarget();

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

    mgr.DeleteTargetSum(calcDate);

    mgr.FillTarget(calcDate);

 

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

 

    string filename = "DALTest_SeperateDB_UnitTest1.txt";

    testDatenmanger.ReadToFile(

        DIRTARGET + filename,

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

 

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

}

<connectionStrings>

  <clear/>

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

</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

Die Tabelle [dbo].[Target_Code] ist in der Datenbank noch leer oder genau mit den passenden IDs gefüllt. Die Testkonstellation muss passen, ansonsten ist der Testfall nicht erfolgreich.

Vorteile

  • Aufwand beim Erstellen der Tests hält sich in Grenzen
  • Daten sind exakt auf die Test zugeschnitten
    • Entwicklungsdaten werden nicht geändert
    • Referenzierte Daten könnten schon vorliegen

Nachteile

  • Weitere Umgebung die aktuell gehalten werden muss
  • Möglicher hoher Aufwand bei neuen Testszenarien
    • Sich gegenseitig beeinflussende Tests
    • Testdaten müssen erzeugt und integriert werden

Dieses Vorgehen ist schon mal ein ganzes Stück besser als das vorherige, bei dem die Tests auf der Entwicklungsdatenbank ausgeführt werden. Leider könnten sich hierbei Testfälle gegenseitig beeinflussen oder die Erstellung neuer Testfälle schwierig machen.

zur Übersicht