使用xUnit,EF,Effort和ABP进行单元测试(C#)

返回总目录《一步一步使用ABP框架搭建正式项目系列教程》


本篇目录

介绍###

在这篇博客中,我们来说说基于ABP项目的单元测试。说到单元测试(Unit Test),估计很多人只有在上《软件工程》这门课时才接触过这个概念,平时写代码基本不写测试的,测试的唯一办法就是代码写完后跑一遍,看看符不符合预期的效果,如果符合就算完成任务了。但是,在大公司或者项目比较大(比如开发一个框架)的时候,单元测试很重要,它是保证软件质量的一个重要指标。

在这篇博客中,我会在同一个解决方案中创建一个测试项目,而不是另外创建一个新的解决方案。解决方案的结构如下所示:

图片

我将会测试该项目的应用服务,包括LcErp.Application,LcErp.Core,LcErp.EntityFramework子项目。至于如何使用ABP框架搭建项目,您可以参考之前的文章,本篇单讲测试话题。

创建测试项目###

如果你是用ABP启动模板创建的项目,那么它会自动创建测试项目的,否则,你可以手动创建一个测试项目。比如,我这里创建了一个叫做LcErp.Tests的类库项目,它位于Tests文件夹下。如果你是手动添加的类库项目,请添加下面的nuget包:

  • Abp.TestBase:提供了一些使得测试基于ABP框架应用的测试更为简单的基类。
  • Abp.EntityFramework:使用EF作为ORM。
  • Effort.EF6:使得创建一个伪造的、供EF容易使用的内存数据库成为可能。
  • xunit:这是我们使用的测试框架。此外,也添加了在VS中运行测试的 xunit.runner.visualstudio
  • Shouldly:该包是为了方便书写断言的。

当我们添加了这些包之后,它们的依赖包也会自动添加到项目中。最后,我们要将LcErp.Application,LcErp.Core,LcErp.EntityFramework的引用添加到LcErp项目中,因为我们要测试这些项目。

图片

准备测试基类###

为了使创建测试类更简单,我们要先创建一个基类,该基类准备了一个伪造的数据库连接:

/// <summary>
    /// 这是我们所有测试类的基类。
    /// 它准备了ABP系统,模块和一个伪造的内存数据库。
    /// 具有初始数据的种子数据库。
    /// 提供了容易使用的方法<see cref="LcErpDbContext"/>
    /// </summary>
public abstract class AppTestBase : AbpIntegratedTestBase
{
    protected AppTestBase()
        {
            //Seed initial data
            UsingDbContext(context =>
            {
                new InitialDbBuilder(context).Create();
                new TestDataBuilder(context).Create();
            });

            LoginAsDefaultTenantAdmin();
        }

    protected override void PreInitialize()
        {
            base.PreInitialize();

            //Fake DbConnection using Effort!
            LocalIocManager.IocContainer.Register(
                Component.For<DbConnection>()
                    .UsingFactoryMethod(DbConnectionFactory.CreateTransient)
                    .LifestyleSingleton()
                );
        }

    protected override void AddModules(ITypeList<AbpModule> modules)
        {
            base.AddModules(modules);

            //Adding testing modules. Depended modules of these modules are automatically added.
            modules.Add<LcErpTestModule>();
        }

    #region UsingDbContext

    protected void UsingDbContext(Action<LcErpDbContext> action)
        {
            using (var context = LocalIocManager.Resolve<LcErpDbContext>())
            {
                context.DisableAllFilters();
                action(context);
                context.SaveChanges();
            }
        }

    protected async Task UsingDbContextAsync(Action<LcErpDbContext> action)
        {
            using (var context = LocalIocManager.Resolve<LcErpDbContext>())
            {
                context.DisableAllFilters();
                action(context);
                await context.SaveChangesAsync();
            }
        }

    protected T UsingDbContext<T>(Func<LcErpDbContext, T> func)
        {
            T result;

            using (var context = LocalIocManager.Resolve<LcErpDbContext>())
            {
                context.DisableAllFilters();
                result = func(context);
                context.SaveChanges();
            }

            return result;
        }

    protected async Task<T> UsingDbContextAsync<T>(Func<LcErpDbContext, Task<T>> func)
        {
            T result;

            using (var context = LocalIocManager.Resolve<LcErpDbContext>())
            {
                context.DisableAllFilters();
                result = await func(context);
                await context.SaveChangesAsync();
            }

            return result;
        }

    #endregion

	......这里省略其他方法...

该基类继承了AbpIntegratedTestBase,它是一个初始化了ABP系统的基类,定义了protected IIocManager LocalIocManager { get; }。每个测试都会使用这个专用的IIocManager。因此,测试之间是相互隔离的。

我们重写了AddModules方法来添加我们想要测试的模块(依赖的模块会自动添加)。

在PreInitialize中,我们使用EffortDbConnection注册到依赖注入系统中,注册类型为Singleton。因此,即使我们在相同的测试中创建了不止一个DbContext,也会在一个测试中使用相同的数据库(和连接)。为了使用该内存数据库,LcErp必须有一个获取DbConnection的构造函数。因此,数据库上下文LcErp类中的构造函数会多一个,如下:

/* This constructor is used in tests to pass a fake/mock connection.
 */
public LcErpDbContext(DbConnection dbConnection)
    : base(dbConnection, true)
{

}


在AppTestBase的构造函数中,我们也在数据库中创建了一个初始化数据(initial data)。这是很重要的,因为一些测试要求数据库中存在的数据。InitialDbBuilder类填充数据库的内容如下(详细信息可自行查看项目):


public class InitialDbBuilder
{
    private readonly LcErpDbContext _context;

    public InitialDbBuilder(LcErpDbContext context)
    {
        _context = context;
    }

    public void Create()
    {
        _context.DisableAllFilters();

        new DefaultEditionCreator(_context).Create();
        new DefaultLanguagesCreator(_context).Create();
        new DefaultTenantRoleAndUserCreator(_context).Create();
        new DefaultSettingsCreator(_context).Create();

        _context.SaveChanges();
    }
}

AppTestBase的UsingDbContext方法使得当需要直接使用DbContext连接数据库时创建DbContext更容易。在构造函数中我们使用了它,接下来我们将会在测试中看到如何使用它。

我们所有的测试类都会从AppTestBase继承。因此,所有的测试都会通过初始化ABP启动,使用一个具有初始化数据的伪造数据库。为使测试更容易,我们也可以给这个基类添加通用的帮助方法。

创建第一个测试###

接下来,我们正式创建第一个单元测试。下面的ProductionOrderAppService类中有一个CreateOrder方法,定义如下:

public class ProductionOrderAppService : LcErpAppServiceBase, IProductionOrderAppService
{
    private readonly IRepository<Order> _orderRepository;
    public ProductionOrderAppService(IRepository<Order> orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public void CreateOrder(CreateOrderInput input)
    {
        var order = input.MapTo<Order>();//将dto对象映射为实体对象
        _orderRepository.Insert(order);
    }

	......其他方法
}

一般来说,单元测试中,测试类的依赖是假的(通过使用一些模仿框架如Moq和NSubstitute来创建伪造的实现)。这使得单元测试更加困难,特别是当依赖逐渐增多时。

我们这里不会这样处理,因为我们使用了依赖注入,所有的依赖会通过具有真实实现的依赖注入自动填充,而不是伪造。我们伪造的东西只有数据库。实际上,这是一个集成测试,因为它不仅测试了ProductionOrderAppService,还测试了仓储,甚至我们测试了验证,工作单元和ABP的其他基础设施。这是非常具有价值的,因为我们正在更加真实地测试这个应用程序。

现在,我们开始创建第一个测试来测试CreateOrder 方法。

public class ProductionOrderAppService_Tests:AppTestBase
    {
        private readonly IProductionOrderAppService _orderAppService;

        public ProductionOrderAppService_Tests()
        {
            //创建被测试的类(SUT-Software Under Test[被测系统])
            _orderAppService = LocalIocManager.Resolve<IProductionOrderAppService>();
        }

        [Fact]
        public void Should_Create_New_Order()
        {
            //准备测试
            var initialCount = UsingDbContext(ctx => ctx.Orders.Count());

            //运行被测系统
            _orderAppService.CreateOrder(new CreateOrderInput
            {
                Amount = 10,
                CustomerId = 10,
                OrderId = "abc",
                OrderrDateTime = DateTime.Now,
                OrderUserId = 10,
                Sum = 10,
                Remark = "测试一" 
            });

            _orderAppService.CreateOrder(new CreateOrderInput
            {
                    OrderId = "efd",
                    Remark = "测试二"
            });

            //校验结果

            UsingDbContext(ctx =>
            {
                ctx.Orders.Count().ShouldBe(initialCount+2);
                ctx.Orders.FirstOrDefault(o=>o.Remark=="测试一").ShouldNotBe(null);
                var order2 = ctx.Orders.FirstOrDefault(o => o.OrderId == "efd");
                order2.ShouldNotBe(null);
                order2.Remark.ShouldBe("测试二");
                //Assert.Equal("测试二",order2.Remark);

            });

        }

    }

正如之前所讲,我们继承了AppTestBase这个测试基类。在一个单元测试中,我们首先应该创建被测试的对象。在上面的构造函数中,使用LocalIocManager(依赖注入管理者)来创建了一个 IProductionOrderAppService(因为ProductionOrderAppService实现了IProductionOrderAppService,所以会创建ProductionOrderAppService)。通过这种方法,就避免了创建伪造的依赖实现。

Should_Create_New_Order是测试方法。它使用了xUnit的 Fact特性进行修饰。这样,xUnit就理解了这是个测试方法,然后运行这个方法。

在一个测试方法中,我们一般遵循包含三步骤的AAA模式:

  1. Arrange:为测试准备
  2. Act:运行SUT(实际测试的代码)
  3. Assert:校验结果

在Should_Create_New_Order方法中,我们创建了2个订单,因此,我们的三步骤是:

  1. Arrange:我们获取数据库中的订单总数量
  2. Act:使用_orderAppService.CreateOrder添加了2个订单
  3. Assert:检查订单数量是否增加了2个。同时尝试从数据库中获取订单,以检查订单是否被正确地插入到数据库中。

这里,我们使用了UsingDbContext方法来直接使用DbContext。如果测试成功,我们就知道了当输入合理时,CreateOrder方法可以创建订单。

要运行测试,我们要打开VS的测试管理器,选择测试->窗口->测试资源管理器(如果没有找到刚才创建的测试类和方法,先保存生成一下):

图片
选中刚才创建的测试,右键“运行该测试”:
图片

如上所示,我们的第一个单元测试通过了。恭喜恭喜!如果测试或者测试代码不正确,那么测试会失败!

假设我注释掉第二个订单对象的Remark的赋值,然后再次运行测试,结果会失败:

图片

Shouldly类库使得失败信息更加清晰,也使得编写断言更加容易。比较一下xUnit的 Assert.Equal和 Shouldly的 ShouldBe扩展方法:

order2.Remark.ShouldBe("测试二");//使用Shouldly
Assert.Equal("测试二",order2.Remark);//使用xUnit的Assert
     

第一个读写更简单且自然,并且Shouldly提供了很多其他的扩展方法来方便我们的编程,请查看Shouldly相应的文档。

测试异常###

我想为CreateOrder方法再创建一个测试方法,但是,这次输入不合法

[Fact]
public void Should_Not_Create_New_Order_WithoutOrderId()
{
    Assert.Throws<AbpValidationException>(() => _orderAppService.CreateOrder(new CreateOrderInput 
    {
            Remark = "该订单的OrderId没有赋值"
    }));
}


如果没有为创建的订单的OrderId属性赋值,那么我期望CreateOrder会抛异常。因为在CreateOrderInput DTO类中,OrderId被标记为 Required,所以,如果CreateOrder抛出异常,测试就会成功,否则失败。注意:验证输入和抛异常是ABP基础设施处理的。

测试结果如下:

图片

在测试中使用仓储###

下面在测试方法中使用仓储,改造上面创建订单的测试方法:

        [Fact]
        public void Should_Create_New_Order()
        {
            //准备测试
            //var initialCount = UsingDbContext(ctx => ctx.Orders.Count());
            //使用仓储代替DbContext
            var orderRepo = LocalIocManager.Resolve<IRepository<Order>>();

            //运行被测系统
            _orderAppService.CreateOrder(new CreateOrderInput
            {
                Amount = 10,
                CustomerId = 10,
                OrderId = "abc",
                OrderrDateTime = DateTime.Now,
                OrderUserId = 10,
                Sum = 10,
                Remark = "测试一" 
            });

            _orderAppService.CreateOrder(new CreateOrderInput
            {
                    OrderId = "efd",
                    Remark = "测试二"
            });

            //校验结果

            //UsingDbContext(ctx =>
            //{
            //    ctx.Orders.Count().ShouldBe(initialCount+2);
            //    ctx.Orders.FirstOrDefault(o=>o.Remark=="测试一").ShouldNotBe(null);
            //    var order2 = ctx.Orders.FirstOrDefault(o => o.OrderId == "efd");
            //    order2.ShouldNotBe(null);
            //    order2.Remark.ShouldBe("测试二");
            //    //Assert.Equal("测试二",order2.Remark);
            //});

            orderRepo.GetAllList().Count.ShouldBe(2);

        }


测试异步方法###

我们也可以使用xUnit测试异步方法。比如,ProductionOrderAppService的GetAllOrders方法是异步方法,那么测试方法也应该是异步的(async)。

[Fact]
public async Task Should_Get_All_People()
{
    var output = await _orderAppService.GetAllPeople();
    output.People.Count.ShouldBe(4);
}

小结###

这篇文章中,我只想展示一下基于ABP框架搭建的项目的测试。ABP提供了一个很好的基础设施来实现测试驱动开发(TDD),或者为你的应用程序简单地创建一些单元测试或集成测试。

Effort类库提供了一个伪造的数据库,它和EF协作地很好。只要你使用了EF或者Linq来执行数据库操作,它就会工作。如果你使用了存储过程,并想测试它,那么Effort不支持。对于这些情况,建议使用LocalDB。

posted @ 2016-04-06 17:19  tkbSimplest  阅读(...)  评论(...编辑  收藏