在 AutoFixture 自定义上调用 Dispose 方法答案

【问题标题】：Invoke Dispose method on AutoFixture customization在 AutoFixture 自定义上调用 Dispose 方法
【发布时间】：2013-03-19 10:07:10
【问题描述】：

我正在使用 AutoFixture 自定义来测试访问 SQL Compact DB 的存储库。

测试完成后立即删除此数据库对我很有帮助。因为 db 是在自定义构造函数中创建的，所以我认为删除它的最佳位置是在 dispose 方法中。

我想的代码是：

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);
        }
    }
}

有可能做类似的事情吗？

【问题讨论】：

DisposableTrackingCustomization 在 AutoFixture 中可以以不同的方式使用并管理与此类似的东西（看看它的 impl）什么测试框架（有 xUnit 的 hacks 可以节省使用 using和/或调用`Fixture.Dispose()）？使用 AutoFixture.xUnit.net 吗？另见github.com/AutoFixture/AutoFixture/issues/17

标签： c# integration-testing autofixture

【解决方案1】：

正如@Ruben Bartelink 在 cmets 中指出的那样，可能。但是，我会推荐一种不同的方法，原因如下。

管理对象的生命周期是您通常期望能够使用 IoC 容器执行的操作。然而，AutoFixture，尽管它可能看起来是一个 IoC 容器，但它实际上是 not meant to be one：

AutoFixture 与 DI 容器有很多相似之处。它支持自动装配，可以配置为在很多有趣的方式。但由于关注点不同，有些事情做得更好，有些事情不如 DI 容器。

AutoFixture 的主要目标是在一些可配置的范围内轻松创建anonymous test data。它的 API 专注于允许程序员自定义如何生成测试数据，而不是多久它将存在，因为假设它只被消耗within the context of a test：

AutoFixture 在生命周期方面较弱管理。一个夹具的存在时间永远不会超过一个单个测试用例，因此对任何其他生活方式进行建模是没有意义的比 Transient 和 Singleton。 [...] 它没有 to，因为它不是 DI Container。

另一方面，测试框架非常擅长管理测试装置的生命周期。由于您所描述的通常是管理集成测试的 context 的一部分，因此我会在 before 和 after 中的所有测试中运行它夹具被执行。

例如：

[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
    } 
}

然后您的测试可以继承上下文并使用它来配置 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()
    {
        // ...
    }
}

在这种情况下，利用测试框架来管理临时数据库的生命周期可以清楚地传达其在测试上下文中的边界。在我看来，将其隐藏在 AutoFixture 自定义项中会使其变得不那么明显，并且可以说更难使用。

【讨论】：