单元测试异步数据库方法

Unit testing async database methods

我有一个 Web API,我想使用 MS Test 对其进行测试。我想特别测试一个控制器。这是初始化代码:

public class MyControllerTests
{
    private static MyController controller;

    [AssemblyInitialize]
    public static void Initialize(TestContext context)
    {
        controller = new MyController();

        IoC.Register(Component.For<IDbContextFactory>().ImplementedBy<MockDbContextFactory>());
        // other config
    }
    // test methods, all async
}

这是模拟上下文工厂。它是否在所有 API 方法中用于获取数据库上下文。

public class MockDbContextFactory : IDbContextFactory
{
    MyContext context;

    public MyBaseContext GetContext()
    {
        if (context == null)
        {
            context = new MyContext(new DropCreateDatabaseAlways<MyContext>());

            //populate with mock data...
        }

        return context;
    }
}

在我为 delete 方法添加测试之前,一切都很好。它在其他方法之前完成,因此它从共享上下文中删除对象并且其他测试失败。不,我有两个想法:每个方法的新上下文(使用 [TestInitialize] 重置器),但底层数据库仍然相同,并且在插入新的模拟对象时我遇到很多键冲突。另一个想法是在内存中设置一个新的数据库并拥有完全独立的实例。我找到了 Effort,但我认为这是一种矫枉过正的做法,而且我的做法是错误的。

我正在使用 Castle Windsor 作为 IoC 容器,以防有办法在 IoC 级别上做到这一点。

我想你可能看错了。

单元测试的目的是测试与任何其他单元隔离的功能单元。不需要单元测试Entity Framework,它已经被彻底测试过了。任何时候创建 CRUD 操作的测试,实际上都是在创建集成测试,而不是单元测试。

如果您确实需要测试您的 CRUD 操作,那么您的模拟工厂应该只返回传递给它的所有操作的成功,或者在本地保存数据以传回以供验证。它不应该创建一个 "test" DbContext 对象,它不仅要与数据库交互,还要与其他测试交互。您的单元测试应该只专注于验证被测函数中的操作。

现在,如果您打算执行集成测试,那么通常的做法是让测试本身插入要删除的对象。让删除测试尝试删除由另一个测试插入的记录在时间上总是一个挑战。此外,甚至没有理由担心删除插入测试插入的对象,使用 DropCreateDatabaseAlways.