模型的四种血量分类：
失血模型：property都是 { get; set; }，没有任何业务逻辑。
贫血模型：比如property的get内部有业务逻辑，业务逻辑由模型内部数据即可计算得出，不依赖于外部。
充血模型：比如property的get内部有业务逻辑，业务逻辑依赖于外部接口，比如持久化接口。
胀血模型：模型内部直接实现所有依赖，接口都不需要了。
模型和上下文场景
class Order
{
DateTime CreatedTime { get; }
List<Item> 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<IOrderManage> mockOrderManager
public void ConsumerABusiness()
{
mockOrderManager.Setup(x => x.GetOrder()).Returns(new Order { Items = new List<Item> { 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>对象解决问题，但是感觉只是为了解决问题而改动，我们需要更好的方案
现在，如果是你负责在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<IOrderService>解决。
