微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

c# – 在AutoFixture自定义上调用Dispose方法

我正在使用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);
        }
    }
}

有可能做类似的事情吗?

解决方法

正如@Ruben Bartelink在评论中指出的那样,这是有可能的.但是,我会推荐一种不同的方法,这就是原因.

管理对象的生命周期是您通常希望能够对IoC容器执行的操作.但是,AutoFixture虽然看起来像IoC容器,但它确实是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的主要目标是在一些可配置的范围内轻松创建anonymous test data.它的API专注于允许程序员自定义测试数据的生成方式,而不是生成测试数据的时间,因为假设它只被消耗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.

另一方面,测试框架非常擅长管理测试夹具的使用寿命.由于您所描述的内容通常是管理集成测试的上下文的一部分,因此我会在执行夹具中的所有测试之前和之后运行它.

例如:

[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定制中会使它更不明显,并且可以说更难以使用.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


原文地址:http://msdn.microsoft.com/en-us/magazine/cc163791.aspx 原文发布日期: 9/19/2005 原文已经被 Microsoft 删除了,收集过程中发现很多文章图都不全,那是因为原文的图都不全,所以特收集完整全文。 目录 前言 CLR启动程序
前言 随着近些年微服务的流行,有越来越多的开发者和团队所采纳和使用,它的确提供了很多的优势也解决了很多的问题,但是我们也知道也并不是银弹,提供优势的同时它也给我们的开发人员和团队也带来了很多的挑战。 为了迎接或者采用这些新技术,开发团队需要更加注重一些流程或工具的使用,这样才能更好的适应这些新技术所
最近因为比较忙,好久没有写博客了,这篇主要给大家分享一下PLINQ中的分区。上一篇介绍了并行编程,这边详细介绍一下并行编程中的分区和自定义分区。 先做个假设,假设我们有一个200Mb的文本文件需要读取,怎么样才能做到最优的速度呢?对,很显然就是拆分,把文本文件拆分成很多个小文件,充分利用我们计算机中
在多核CPU在今天和不久的将来,计算机将拥有更多的内核,Microsoft为了利用这个硬件特性,于是在Visual Studio 2010 和 .NET Framework 4的发布及以上版本中,添加了并行编程这个新特性,我想它以后势必会改变我们的开发方式。 在以前或者说现在,我们在并行开发的时候可
c语言输入成绩怎么判断等级
字符型数据在内存中的存储形式是什么
c语言怎么求字符串的长度并输出
c语言函数的三种调用方式是什么
c语言中保留两位小数怎么表示
double的输入格式符是什么