单元测试引出重构贫血模型的尝试

模型的四种血量分类：

失血模型：property都是 { get; set; }，没有任何业务逻辑。
贫血模型：比如property的get内部有业务逻辑，业务逻辑由模型内部数据即可计算得出，不依赖于外部。
充血模型：比如property的get内部有业务逻辑，业务逻辑依赖于外部接口，比如持久化接口。
胀血模型：模型内部直接实现所有依赖，接口都不需要了。

模型和上下文场景

class Order
{
    DateTime CreatedTime { get; }

    List Items { get; }

    bool IsAvailable 
    { 
        get 
        { 
            return Items.Count > 0; 
        }
    }
}

Order是贫血模型，没有外部接口依赖。
Order的property IsAvailable是我们关注和重构的核心。
Order的物理结构不会变化，业务复杂性只在IsAvailable的逻辑规则上增长。
Order由OrderManage的GetOrder方法提供实例。
IsAvailable被广泛使用，如下所示各种consumer。

class OrderManager : IOrderManage
{
    public Order GetOrder() {...}
}

class OrderConsumerA
{
    IOrderManage OrderManager

    public void ConsumerABusiness()
    {
        var isOrderAvailable = OrderManager.GetOrder().IsAvailable;
        ...
    }
}

class OrderConsumerB
{
    IOrderManage OrderManager

    public void ConsumerBBusiness()
    {
        var isOrderAvailable = OrderManager.GetOrder().IsAvailable;
        ...
    }
}

class OrderConsumerC
{
    IOrderManage OrderManager

    public void ConsumerCBusiness()
    {
        var isOrderAvailable = OrderManager.GetOrder().IsAvailable;
        ...
    }
}

单元测试代码

使用单元测试框架Mock

class OrderConsumerATests
{
    Mock mockOrderManager

    public void ConsumerABusiness()
    {
        mockOrderManager.Setup(x => x.GetOrder()).Returns(new Order { Items = new List { new Item() }});
        ...
    }
}

Order是Model，没有基于抽象定义。无法使用Mock框架构造一个fake的IsAvailable实现去直接返回我们testcase期望的结果。因此需要在每个testcase内构建一个Order实例。
当业务逻辑简单且模型结构简单时，那么在各个consumer单元测试中重复构造整个对象并不费力，我们不觉得痛，还可以接受的。

但是，IsAvailabled的业务逻辑变复杂时

class Order
{
    bool IsAvailable 
    { 
        get 
        { 
            return Items.Count > 0 && (CreatedTime.AddDays(7) >= DateTime.Now || (Items.All(item => !item.HasInventory) && Items.Sum(item => item.Price) < MaximumPrice)) ; 
        }
    }
}

复杂度上升，导致构造适合每个testcase的Order对象变得复杂，IsAvailable内部逻辑在每个testcase中都会被执行一次。维护单元测试就变得越来越困难，这是痛点。

想法

单元测试只关心单元内部的逻辑和实现，不要有类似于集成测试的单元测试
单元测试准备数据的过程不要太繁琐，写单元测试不要被准备数据的过程所阻碍
给IsAvailable一个virtual关键字就可以使用Mock对象解决问题，但是感觉只是为了解决问题而改动，我们需要更好的方案

现在，如果是你负责在Order的IsAvailable上再增加业务逻辑，面对越来越难以维护的单元测试，你会怎么重构代码？你会怎样继续写单元测试去覆盖新增加的业务逻辑？现在，不妨停下来思考一下先.

OK，已有的想法是，

1. 纵向-提取抽象到父类

给Order 一个父类OrderBase，对应的abstract/virtual 关键字体现抽象。接下来只要Mock的setup就好了，不必多说。

class OrderBase
{
  virtual bool IsAvailable(Order order);
}

Order上方的父类就是对业务逻辑抽象结构的体现。理论上讲与virtual IsAvailable性质一样，但是在model整体上做到了面向对象，面向抽象。
这种抽象是对model本身结构的抽象。

2. 横向-提取逻辑到接口

另外一条思路就是提取新的接口IOrderService，业务逻辑向接口实现中迁移。所以这种方法会让模型流血，有反内聚的嫌疑，但是是否适用得具体问题具体分析。

interface IOrderService
{
   bool IsAvailable(Order order);
}

然后，Consumer引入

class OrderConsumerA
{
    IOrderManage OrderManager

    IOrderService OrderService

    public void ConsumerABusiness()
    {
        var isOrderAvailable = OrderService.IsAvailable(OrderManager.GetOrder());
        ...
    }
}

或者更彻底一些，直接由OrderService依赖IOrderManage，Consumer只依赖OrderService。
这种抽象是对IsAvailable逻辑的抽象。

总之，业务逻辑迁移到了service。之后我们的单元测试问题可以使用Mock解决。