Nachteil der Verwendung der Transaktion dispose mit Entity Framework Integrationstest

Question

Ich bin auf der Suche nach einer schnellen Möglichkeit, meine Tabellen Daten zu reinigen, die Integration Tests mit EF.

Jeder scheint eine Transaktion um seine Testmethode zu wickeln und die Transaktion nach dem Test zu entsorgen.

Auf diese Weise werden die Daten nie in die Tabelle geschrieben.

Dinge wie neue Auto IDs für Inserts funktionieren noch, aber ich frage mich, ob diese Methode wirklich zuverlässig ist im Vergleich zu .commit() der Transaktion.

Gibt es irgendwelche Nachteile diesen Ansatz zu verwenden, die nicht scheint, ein echten Integrationstest zu sein, wie die Datenbank nie berührt wird ...

Oder mit anderen Worten geben es fehlerhafte Szenarien gefragt, die als Ausnahmen nicht Pop mit die Transaktion ohne commit()?

UPDATE

public abstract class IntegrationTestsBase 
    { 
     protected TransactionScope TransactionScope; 

     public abstract void TestSetup(); 
     protected void InitTestSetupOnTable(string tableName) 
     { 
      TransactionScope = new TransactionScope(); 

      using (var context = new TGBContext()) 
      { 
       var cmdCommand = string.Format("DBCC CHECKIDENT ({0}, RESEED, 1)", tableName); 
       context.Database.ExecuteSqlCommand(cmdCommand); 
       context.SaveChanges(); 
      } 
     } 

     [TestCleanup] 
     public void TestCleanup() 
     { 
      TransactionScope.Dispose(); 
     } 
    } 

[TestClass] 
public class MyTests : IntegrationTestsBase 
{ 
     [TestInitialize] 
     public override void TestSetup() 
     { 
      base.InitTestSetupOnTable("MyTableName");   
     } 
} 

Answer 1

wie die Datenbank nie berührt

Sicherlich ist es berührt. Alles, was innerhalb der Transaktion passiert, passiert in der Datenbank. Identity-Werte und -Sequenzen (falls vorhanden) werden inkrementiert, Trigger ausgelöst, referentielle Constraints überprüft, usw. Das einzige Problem ist, dass es isoliert geschieht und am Ende alles (außer inkrementierten Identitäten und Sequenzen) zurückgesetzt wird.

Gibt es Nachteile bei der Verwendung dieses Ansatzes?

Nicht wirklich. Ich verwende diesen Ansatz ausführlich in meinem eigenen Code und es hat große Vorteile. Grüne Tests geben ein sehr hohes Maß an Sicherheit. Ich werde mich nie sicher fühlen mit "echten" Unit Test mit gespotteten Kontexten und DbSet 's (obwohl ich Unit-Test für viele andere Dinge verwenden).

Aber es gibt einige Einschränkungen, die Sie beachten sollten.

• Identitäts-/Sequenzwerte sind nicht deterministisch, daher können Sie sie nicht bestätigen. Wie gesagt, diese Werte werden nicht zurückgesetzt. Wenn Sie in diesem Bereich wirklich Bestätigungen benötigen, können Sie die Identitäten/Sequenzen nach jedem Test zurücksetzen.
• Wir können nie Concurrency-Probleme mit diesem Ansatz testen.
• Sie können keine Verbindung zu einer anderen Datenbank oder sogar zu derselben Datenbank herstellen, wenn sich die Verbindungszeichenfolge im geringsten Detail unterscheidet (z. B. ein anderer Anwendungsname oder eine andere MARS-Einstellung), ohne dass DTC eintritt. In der Anwendung Code wäre dies möglich, weil dort diese verschiedenen Anrufe nicht in eine TransactionScope gewickelt werden würde. Vielleicht können nicht alle Anwendungspfade auf diese Weise einfach getestet werden.
• Entwickler sollten ihre eigene Kopie der Testdatenbank verwenden. Wenn mehrere Entwickler (und möglicherweise ein Build-Server) Tests für dieselbe Datenbank ausführen, können sie sich gegenseitig blockieren.