entity-framework - 使用事务处理与 Entity Framework 集成测试的缺点

Question

我正在寻找一种使用 EF 进行集成测试的快速方法来清理我的表数据。

每个人似乎都围绕其测试方法包装事务，并在测试后处理事务。

这样，数据永远不会写入表。

像插入的新自动 id 之类的东西仍然有效，但我问自己，与 .commit() 事务相比，这种方法是否真的可靠。

使用这种似乎不是真正的集成测试的方法是否有任何缺点，因为数据库从未被触及......

或者换句话说，是否存在使用没有 commit() 的事务不会作为异常弹出的错误场景？

更新

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 is never touched

肯定是被触动了。事务中发生的一切都发生在数据库中。标识值和序列(如果有)增加，触发触发，检查引用约束等。唯一的事情是，它是孤立发生的，最后一切(除了增加的标识和序列)都被还原。

Are there any downsides of using this approach?

并不真地。我在自己的代码中广泛使用了这种方法，它有很大的优点。绿色测试提供了非常高水平的保证。我永远不会对使用模拟上下文和 DbSet 的“真实”单元测试感到安全。 's(虽然我在许多其他事情上使用单元测试)。

但是，您应该注意一些限制。

身份/序列值不是确定性的，因此您无法断言它们。正如我所说，这些值不会回滚。如果您确实需要在这方面进行断言，您可以在每次测试后重置身份/序列。

我们永远无法通过这种方法测试并发问题。

如果没有 DTC 介入，您无法打开到另一个数据库的连接，甚至不能打开到同一个数据库的连接，如果它的连接字符串在最细微的细节上有所不同(例如，不同的应用程序名称，或不同的 MARS 设置)。在应用程序代码中，这将是可能的，因为这些不同的调用不会包含在 TransactionScope 中.因此，可能并非所有应用程序路径都可以通过这种方式轻松测试。

开发人员应该使用他们自己的测试数据库副本。如果多个开发人员(可能还有一个构建服务器)在同一个数据库上运行测试，他们可能会彼此死锁。