Mit diesem Vorgehen ist es zwar möglich jede Datenbank zu schützen, aber Vorzugweise verwende ich die Entwicklungsdatenbank.

Testablauf am Beispiel der Referenzanwendung

1. Ein TransactionContext wird erstellt.
2. Die Entwicklungsdaten werden gelöscht.
3. Die Testdaten zum 1.1.2014 werden in die Tabelle [dbo].[Source] eingespielt.
4. Die Tabelle [dbo].[Target_Sum] wird gelöscht.
   • [dbo].[Delete_Target_Sum_ByCalcDate]
5. Die Tabelle [dbo].[Target_Sum] wird befüllt.
   • [dbo].[Insert_Target_ByCalcDate]
6. 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.
7. Der TransactionContext wird zurückgerollt.

TransactionScope m_transactionScope;

DBManager m_testDatenmangerRoot;

[TestInitialize]

public void Init()

{

    m_transactionScope = new TransactionScope(TransactionScopeOption.Required);

    m_testDatenmangerRoot = new DBManager("ROOT", true);

    m_testDatenmangerRoot.ExecFile(@".ScripteInsertData.sql");

}

[TestMethod]

public void DALTest_Transaction()

{

    DBManagerTarget mgr = new DBManagerTarget();

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

    mgr.DeleteTargetSum(calcDate);

    mgr.FillTarget(calcDate);

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

    string filename = "DALTest_Transaction_UnitTest1.txt";

    testDatenmanger.ReadToFile(

        DIRTARGET + filename,

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

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

}

[TestCleanup]

public void CleanUp()

{

    //no transactionScope.Complete();

    m_transactionScope.Dispose();

    m_transactionScope = null;

    m_testDatenmangerRoot = null;

}

<connectionStrings>

  <clear/>

  <add name="ROOT" connectionString="...;Initial Catalog=DBTesting;...User Id=sa;..."/>

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

</connectionStrings>

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');

...

Damit die technischen IDs der Tabelle [dbo].[Target_Code] korrekt erzeugt werden ist ein TRUNCATE nötig. Hierdurch wird der Zähler des Inkrements der ID Spalte zurückgesetzt.

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

Da die Datenbank für jedes Testszenario neu aufbereitet wird, kann die Tabelle [dbo].[Target_Code] nie mit falschen Werten gefüllt sein.

Vorteile

• Aktuellster Softwarestand (Bei Verwendung der Entwicklungsdatenbank)
• Daten sind exakt auf die Test zugeschnitten
  • Entwicklungsdaten werden nicht geändert
  • Sogar IDENTITY Spalten können exakt getestet werden
• Pro Testszenarien eigene Initialisierung möglich

Nachteile

• Laufzeiten der Tests
• Komplexität des Tests steigt
  • Löschen der Entwicklungsdaten
  • Referenzierte Daten werden beim Skripten leicht übersehen
• Ggf. hoher Aufwand bei Fehlersuche, da Daten am Ende verloren gehen
• Fatale Folgen wenn Testfälle ohne TransactionContext laufen sollten

Dieses Vorgehen ist adaptiv zu allen vorherigen zusehen. Es könnte sogar auf eine neu generierte Datenbank angewendet werden. Die meisten Vorzüge ergeben sich aber bei der Verwendung mit der Entwicklungsdatenbank. Aber auch die Kombination mit einer separaten Testdatenbank bringt viele Vorteile.

zur Übersicht