The disadvantage of using a transaction with entity infrastructure integration testing

Question

I am looking for a quick way to clear the data from my tables performing integration tests with EF.

It seems that all transactions flow around with their testing method and delete the transaction after the test.

Thus, data is never written to the table.

Things like the new automatic IDs for inserts still work, but I ask myself how reliable is this method compared to .commit () transaction.

Are there any flaws in using this approach that do not seem to be a real integration test since the database never gets under way ...

Or, in other words, faulty scripts arise that do not appear as exceptions using a transaction without 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

as the database never starts

Of course, this affected. Everything that happens in the transaction happens in the database. Identification values ​​and sequences (if any) increase, fire starts, reference restrictions are checked, etc. Etc. The only thing that happens happens in isolation and, in the end, everything (except for incremented identities and sequences) returns.

Are there any disadvantages to using this approach?

Not really. I use this approach extensively in my own code, and it has great merit. Green tests give a very high level of confidence. I will never feel safe with the “real” unit test using mocking contexts and DbSet (although I use unit test for many other things).

But there are some limitations you should be aware of.

• Identity / sequence values ​​are not deterministic, so you cannot assert them. As I said, these values ​​will not be canceled. If you really need statements in this area, you can reset identifiers / sequences after each test.
• We cannot test concurrency problems this way.
• You cannot open a connection to another database or even to the same database if its connection string differs in the smallest details (for example, a different application name or another MARS setting) without using a DTC. this would be possible because these different calls would not be wrapped in a TransactionScope . Therefore, perhaps not all application paths can be easily tested in this way.
• Developers should use their own copy of the test database. If several developers (and possibly the build server) run tests in the same database, they can block each other.