调用AutoFixture定制Dispose方法 [英] Invoke Dispose method on AutoFixture customization

问题描述

我使用的是AutoFixture定制，以测试其访问SQL精简DB库。

将是对我很大的帮助，以尽快删除该数据库测试完成。由于分贝是在自定义构造函数创建我认为最好的地方，删除它在dispose方法

而我想的代码是：

<预类=郎-CS prettyprint-覆盖> 内部类ProjectRepositoryCustomization：ICustomization
{
私人只读字符串_dbLocation;

公共ProjectRepositoryCustomization（）
{
变种tempDbLocation = Path.Combine（Path.GetTempPath（），TempDbToDelete）; （！Directory.Exists（tempDbLocation））
如果
{
Directory.CreateDirectory（tempDbLocation）;
}

_dbLocation = Path.Combine（tempDbLocation，Guid.NewGuid（）的ToString（N）+将.sdf）;
}

公共无效自定义（IFixture夹具）
{
DataContextConfiguration.database = _dbLocation;

变种dataContextFactory =新BaseDataContextFactory（）;
变种projRepository =新ProjectRepository（dataContextFactory）;
fixture.Register（（）=> projRepository）;
}

公共无效的Dispose（）
{
如果（File.Exists（_dbLocation））
{
File.Delete（_dbLocation ）;
}
}
}


可以做同样的事情？

解决方案

由于@Ruben Bartelink在评论中指出，这是的可能的。不过，我会建议不同的方法，这里的原因。

管理对象的生命周期是你通常会期望能够与IoC容器做。 AutoFixture，但是，即使它的看起来像的IoC容器，它是真正的并不意味着是之一：

AutoFixture分享了很多DI容器相似之处。它
支持自动布线和它可以被配置为创建在
许多有趣的方式的实例。然而，由于侧重点有所不同，它
做一些事情变得更好，有些事情不是还有一个DI容器。

AutoFixture的主要目标是可以很容易地创建一些配置的范围内匿名测试数据的。它的API的重点是允许程序员自定义的如何的测试数据生成，但不是的多久的它会生活，因为它认为只是消费的测试的范围内：

AutoFixture较弱，当谈到终身
管理。灯具是从未预料到存在超过一个
单一的测试案例比较多，所以它是没有意义的模拟任何其他生活方式
比的瞬态和辛格尔顿。 [...]它没有
到，因为它不是一个DI容器。

测试框架，上另一方面，处于管理测试夹具的寿命相当不错。因为什么你描述通常是管理的背景的一个集成测试，我想运行它的的一部分之前的和的之后的所有内测试。夹具执行

例如：

<预类=郎-CS prettyprint-覆盖> [的TestFixture]
公共类WithDatabaseContext
{
私人字符串dbLocation;
私人BaseDataContextFactory dataContextFactory

保护BaseDataContextFactory DataContextFactory
{
{返回this.dataContextFactory; }
}

[TestFixtureSetUp]
公共无效FixtureInit（）
{
//初始化dbLocation
//初始化dataContextFactory
}

[TestFixtureTearDown]
公共无效FixtureDispose（）
{
//在dbLocation
}
} $ b $删除文件b

您的测试，然后才能继承的背景下，并用它来配置AutoFixture：

<预类=郎-CS prettyprint-覆盖> [的TestFixture]
公共无效SomeTest：WithDatabaseContext
{
私人IFixture夹具;

[设置]
公共无效的init（）
{
this.fixture =新灯（）;
this.fixture.Register（
（）=>新建ProjectRepository（base.DataContextFactory））;
}

[测试]
公共无效Doing_something_should_return_something_else（）
{
// ...
}
$} b $ b

在这种情况下，利用测试框架，以便管理临时数据库的一生清楚地表达它的边界试验的范围内。它隐藏在AutoFixture定制里面，在我看来，将使其远远不太明显，也可以说很难使用。

I'm using an AutoFixture customization to test a repository which access to a SQL Compact DB.

Would be very helpful to me to delete this database as soon as the test is completed. Because the db is created in the customization constructor I think that the best place to delete it is in the dispose method.

The code which I'm thinking is:

internal class ProjectRepositoryCustomization : ICustomization
{
    private readonly String _dbLocation;

    public ProjectRepositoryCustomization()
    {
        var tempDbLocation = Path.Combine(Path.GetTempPath(), "TempDbToDelete");
        if (!Directory.Exists(tempDbLocation))
        {
            Directory.CreateDirectory(tempDbLocation);
        }

        _dbLocation = Path.Combine(tempDbLocation, Guid.NewGuid().ToString("N") + ".sdf");
    }

    public void Customize(IFixture fixture)
    {   
        DataContextConfiguration.database = _dbLocation;

        var dataContextFactory = new BaseDataContextFactory();
        var projRepository = new ProjectRepository(dataContextFactory);
        fixture.Register(() => projRepository);
    }

    public void Dispose()
    {
        if (File.Exists(_dbLocation))
        {
            File.Delete(_dbLocation);
        }
    }
}

Is possible to do something similar?

解决方案

As @Ruben Bartelink points out in the comments, it is possible. However, I would recommend a different approach and here's why.

Managing the lifetime of objects is something you would normally expect to be able to do with an IoC container. AutoFixture, however, even though it may look like an IoC container, it's really not meant to be one:

AutoFixture shares a lot of similarities with DI Containers. It supports auto-wiring and it can be configured to create instances in lots of interesting ways. However, since the focus is different, it does some things better and some things not as well as a DI Container.

AutoFixture's main goal is to make it easy to create anonymous test data within some configurable bounds. Its API is focused on allowing the programmer to customize how the test data is generated but not how long it will live, since it's assumed to only be consumed within the context of a test:

AutoFixture is weaker when it comes to lifetime management. A Fixture is never expected to exist for more than a single test case, so it makes no sense to model any other lifestyle than Transient and Singleton. [...] It doesn't have to, because it's not a DI Container.

Test frameworks, on the other hand, are pretty good at managing the lifetime of test fixtures. Since what you're describing is typically part of managing the context for an integration test, I would run it before and after all the tests within the fixture are executed.

For example:

[TestFixture]
public class WithDatabaseContext
{
    private string dbLocation;
    private BaseDataContextFactory dataContextFactory

    protected BaseDataContextFactory DataContextFactory
    {
        get { return this.dataContextFactory; }
    }

    [TestFixtureSetUp]
    public void FixtureInit()
    {
        // Initialize dbLocation
        // Initialize dataContextFactory
    }

    [TestFixtureTearDown]
    public void FixtureDispose()
    {
        // Delete file at dbLocation
    } 
}

Your test could then inherit the context and use it to configure AutoFixture:

[TestFixture]
public void SomeTest : WithDatabaseContext
{
    private IFixture fixture;

    [SetUp]
    public void Init()
    {
        this.fixture = new Fixture();
        this.fixture.Register(
            () => new ProjectRepository(base.DataContextFactory));
    }

    [Test]
    public void Doing_something_should_return_something_else()
    {
        // ...
    }
}

In this case, leveraging the test framework in order to manage the lifetime of the temporary database clearly communicates its boundaries within the context of the tests. Hiding it inside an AutoFixture customization, in my opinion, would make it far less obvious and, arguably, harder to use.

这篇关于调用AutoFixture定制Dispose方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！