这篇文章简介一下，如何通过 mock framework，来辅助我们更便利地模拟目标对象的依赖对象，而不必手工敲堆只为了这次测试而存在的辅助类型。
而模拟目标对象的部分，常见的有 stub object, mock object, fake object，本文也会简单介绍一下三者的不同点，并且通过实例，帮助读者快速的 pick up 实战经验。
安装与范例说明
本文的范例，使用 VS2013 为开发工具，mock framework 则是使用 Rhino.Mocks，通过 IoC 的方式，由构造函数来传入 stub/mock/fake object。
注：在 Microsoft Fakes 里面也有内建的 stub object，但是是类似 fake object 的方式产生，而非 Rhino.Mocks, moq 这类 mock framework 是使用动态产生 stub/mock object的方式。Isolating Code under Test with Microsoft Fakes
- 效益：顾客入场时，帮助店员统计出门票收入，确认是否核帐正确
- 角色：Pub 店员
- 目的：根据顾客与相关条件，算出对应的门票收入总值
public interface ICheckInFee
{
decimal GetFee(Customer customer);
}
public class Customer
{
public bool IsMale { get; set; }
public int Seq { get; set; }
}
public class Pub
{
private readonly ICheckInFee _checkInFee;
private decimal _inCome;
public Pub(ICheckInFee checkInFee)
{
this._checkInFee = checkInFee;
}
/// <summary>
/// 入场
/// </summary>
/// <param name="customers"></param>
/// <returns>收费的人数</returns>
public int CheckIn(List<Customer> customers)
{
var result = ;
foreach (var customer in customers)
{
var isFemale = !customer.IsMale;
//女生免费入场
if (isFemale)
{
continue;
}
else
{
//for stub, validate status: income value
//for mock, validate only male
this._inCome += this._checkInFee.GetFee(customer);
result++;
}
}
//for stub, validate return value
return result;
}
public decimal GetInCome()
{
return this._inCome;
}
}
CheckIn 说明：
当顾客进场时，如果是女生，则免费入场。若为男生，则根据 ICheckInFee 接口来取得门票的费用，并累计到 inCome 中。通过 GetInCome() 方法取得这一次的门票收入总金额。
Stub
Stub 通常使用在验证目标回传值，以及验证目标对象状态的改变。
这两种验证方式的重点，都摆在目标对象自身的逻辑。
即测试目标对象时，并不在乎目标对象与外部依赖对象如何互动，关注在当外部相依对象回传什么样的数据时，会导致目标对象内部的状态或逻辑变化。
所以这类的验证方式，是通过 stub object 直接模拟外部依赖回传的数据，来验证目标对象行为是否如同预期。
范例：
第一个测试，是验证收费人数是否符合预期，代码如下：
[TestMethod]
public void Test_Charge_Customer_Count()
{
//Arrange
var stubCheckInFee = MockRepository.GenerateMock<ICheckInFee>();
var target = new Pub(stubCheckInFee);
var customers = new List<Customer>
{
new Customer {IsMale = true},
new Customer {IsMale = false},
new Customer {IsMale = false},
};
decimal expected = ;
//Act
var actual = target.CheckIn(customers);
//Assert
Assert.AreEqual(expected, actual);
}
使用 Rhino.Mocks 相当简单，步骤如下：
- 通过
MockRepository.GenerateStub<T>()，来建立某一个 T 类型的 stub object，以上面例子来说，是建立实现 ICheckInFee 接口的子类。
- 把该 stub object 通过构造函数，传给测试目标对象。
- 定义当调用到该 stub object 的哪一个方法时（例子中是GetFee方法），传入的参数是什么， stub 要回传是什么。
通过 Rhino.Mocks，就这么简单地通过 Lambda 的方式定义 stub object 的行为，取代了原本要自己建立一个实体类型，并实现ICheckInFee 接口，定义 GetFee 要回传的值。
上面的测试案例，是入场顾客人数3人，一男两女，因为目前 Pub 的 CheckIn 方法，只针对男生收费，所以回传收费人数应为1人。
第二个测试，则是验证收费的总数，是否符合预期。测试案例一样是一男两女，而通过 stub object模拟每一人收费为100元，所以预期结果门票收入总数为100。测试程序如下：
[TestMethod]
public void Test_Income()
{
//Arrange
var stubCheckInFee = MockRepository.GenerateMock<ICheckInFee>();
var target = new Pub(stubCheckInFee);
stubCheckInFee.Stub(x => x.GetFee(Arg<Customer>.Is.Anything)).Return();
var customers = new List<Customer>
{
new Customer {IsMale = true},
new Customer {IsMale = false},
new Customer {IsMale = false},
};
//Act
decimal inComeBeforeCheckIn = target.GetInCome();
//Assert
Assert.AreEqual(, inComeBeforeCheckIn);
decimal expectedIncome = ;
//Act
int chargeCustomerCount = target.CheckIn(customers);
var actualIncome = target.GetInCome();
//Assert
Assert.AreEqual(expectedIncome, actualIncome);
}
可以看到这里有两个 Assert，因为我们这里是验证状态的改变，期望在调用目标对象的 CheckIn 方法之前，取得的门票收入应为0。而调用之后，依照这个测试案例，门票收入应为100。
通过这两个测试案例，其实实际要测试的部分是，CheckIn 的方法只针对男生收费这一段逻辑。不管实际 production code，门票一人收费多少，都不会影响到这一份商业逻辑。
怎么根据环境或顾客来进行计价，那是在 production code 中，实现 ICheckInFee 接口的子类，要自己进行测试的，与 Pub 对象无关。这样一来，才能隔离 ICheckInFee 背后的变化。
Mock
使用时机：
上面提到验证对象的第三种方式：「验证目标对象与外部依赖接口的互动方式」，如下图所示：
这听起来可能相当抽象，但在开发中，的确可能会碰到这样的测试需求。
Mock 的验证比起 stub 要复杂许多，变动性通常也会大一点，但往往在验证一些 void 的行为会使用到，例如：在某个条件发生时，要记录 Log。这种情境，用 stub 就很难验证，因为对目标对象来说，没有回传值，也没有状态变化，就只能透过 mock object 来验证，目标对象是否正确的与Log 接口进行互动。
范例：
以这个范例来说，我们想验证的是：在2男1女的测试案例中，是否只呼叫 ICheckInFee 接口两次。程序代码如下：
[TestMethod]
public void Test_CheckIn_Charge_Only_Male()
{
//Arrange
//两男一女
var customers = new List<Customer>
{
new Customer {IsMale = true},
new Customer {IsMale = true},
new Customer {IsMale = false},
};
MockRepository mock=new MockRepository();
ICheckInFee stubCheckInFee = mock.StrictMock<ICheckInFee>();
using (mock.Record())
{
//期望调用ICheckInFee的GetFee()次数为2
//Assert
stubCheckInFee.GetFee(customers.ElementAt());
LastCall.IgnoreArguments()
.Return((decimal) )
.Repeat.Times();
}
using (mock.Playback())
{
var target = new Pub(stubCheckInFee);
//Act
target.CheckIn(customers);
}
}
Fake
使用时机：
当目标对象使用到静态方法，或 .net framework 本身的对象，甚至于针对一般直接相依的对象，我们都可以透过 fake object 的方式，直接仿真相依对象的行为。
范例：
以这例子来说，假设 CheckIn 的需求改变，从原本的「女生免费入场」变成「只有当天为星期五，女生才免费入场」，修改程序代码如下：
01 |
public int CheckIn(List<Customer> customers)
|
05 |
foreach (var customer in customers)
|
07 |
var isFemale = !customer.IsMale;
|
09 |
var isLadyNight = DateTime.Today.DayOfWeek == DayOfWeek.Friday;
|
11 |
if (isLadyNight && isFemale)
|
17 |
//for stub, validate status: income value
|
18 |
//for mock, validate only male
|
19 |
this._inCome += this._checkInFee.GetFee(customer);
|
25 |
//for stub, validate return value
|
碰到 DateTime.Today 这类东西，测试案例就会卡住。总不能每次测试都去改测试机上面的日期，或是只有星期五或非星期五才执行某些测试吧。
所以，我们得透过 Isolation framework 来辅助，针对使用到的组件，建立 fake object。
首先，因为这个例子建立的 fake object，是针对 System.DateTime，所以在测试项目上，针对System.dll来新增 Fake 组件，如下图所示：
可以看到增加了一个 Fakes 的 folder，其中会针对要 fake 的 dll，产生对应的程序代码，以便我们进行拦截与改写。
使用 fake 对象也相当简单，先以测试星期五为例，程序代码如下：
02 |
public void Test_Friday_Charge_Customer_Count()
|
04 |
using (ShimsContext.Create())
|
06 |
System.Fakes.ShimDateTime.TodayGet = () =>
|
09 |
return new DateTime(2012, 10, 19);
|
13 |
ICheckInFee stubCheckInFee = MockRepository.GenerateStub<ICheckInFee>();
|
14 |
Pub target = new Pub(stubCheckInFee);
|
16 |
stubCheckInFee.Stub(x => x.GetFee(Arg<Customer>.Is.Anything)).Return(100);
|
18 |
var customers = new List<Customer>
|
20 |
new Customer{ IsMale=true},
|
21 |
new Customer{ IsMale=false},
|
22 |
new Customer{ IsMale=false},
|
28 |
var actual = target.CheckIn(customers);
|
31 |
Assert.AreEqual(expected, actual);
|
说明如下：
- 在
using (ShimsContext.Create()){} 的范围中，会使用 Fake 组件。
- 当在 fake context 环境下，呼叫到
System.DateTime.Today 时，会转呼叫 System.Fakes.ShimDateTime.TodayGet，并定义其回传值为「2012/10/19」，因为这一天是星期五。
接着就跟原本的测试程序代码一样，当星期五时，只对男生收费。
侦错时，可以看到 DateTime.Today 变成我们仿真的「2012/10/19」，但实际系统日期是「2012/10/15」。
再增加一个星期六的测试案例，程序代码如下：
02 |
public void Test_Saturday_Charge_Customer_Count()
|
05 |
using (ShimsContext.Create())
|
07 |
System.Fakes.ShimDateTime.TodayGet = () =>
|
10 |
return new DateTime(2012, 10, 20);
|
14 |
ICheckInFee stubCheckInFee = MockRepository.GenerateStub<ICheckInFee>();
|
15 |
Pub target = new Pub(stubCheckInFee);
|
17 |
stubCheckInFee.Stub(x => x.GetFee(Arg<Customer>.Is.Anything)).Return(100);
|
19 |
var customers = new List<Customer>
|
21 |
new Customer{ IsMale=true},
|
22 |
new Customer{ IsMale=false},
|
23 |
new Customer{ IsMale=false},
|
29 |
var actual = target.CheckIn(customers);
|
32 |
Assert.AreEqual(expected, actual);
|
因为是星期六，所以1男2女，收费人数为3人。
补充：
连 System.dll 都可以进行 fake object 仿真了，所以即使是我们自定义，直接相依，也可以透过这种方式来仿真。
这样一来，即便是直接相依的对象，也可以进行独立测试了。
但强烈建议，针对自定义对象的部分，这是黑魔法类型的作法，如果没有包袱，建议对象设计还是要采 IoC 方式设计。如果是 legacy code，想要进行重构，摆脱直接相依的问题，则可先透过 fake object 来建立单元测试，接下来进行重构，重构后当对象不直接相依时，再改用上面的 stub/mock 方式来进行测试。
可以参考这篇在 Martin Fowler 网站上的文章：Modern Mocking Tools and Black Magic
注：即使不是在VS2012的环境底下，也可以到 Microsoft Research 上 download Moles: Moles - Isolation framework for .NET使用
结论
今天这篇文章介绍了 stub, mock 与 fake 的用法，但依笔者实际经验，使用 stub 的比例大概是8～9成，使用mock的比例大概仅1～2成。而 fake 的方式，则用在特例，例如静态方法跟 .net framework 原生组件。
也请读者朋友务必记得几个基本原则：
-
同一测试案例中，请避免 stub 与 mock 在同一个案例一起验证。原因就如同一直在强调的单元测试准则，一次只验证一件事。而 stub 与 mock 的用途本就不同，stub 是用来辅助验证回传值或目标对象状态，而 mock 是用来验证目标对象与相依对象互动的情况是否符合预期。既然八竿子打不着，又怎么会在同一个测试案例中，验证这两个完全不同的情况呢？
- Mock 的验证可以相当复杂，但越复杂代表维护成本越高，代表越容易因为需求异动而改变。所以，请谨慎使用 mock，更甚至于当发生问题时，针对问题的测试案例才增加 mock 的测试，笔者都认为是合情合理的。
- 当要测试一个目标对象，要 stub/mock/fake 的 object 太多时，请务必思考目标对象的设计是否出现问题，是否与太多细节耦合，是否可将这些细节职责合并。
-
当测试程序写的一狗票落落长时，请确认目标对象的职责是否太肥，或是方法内容太长。这都是因为目标对象设计不良，导致测试程序不容易撰写或维护的情况。问题根源在目标对象的设计质量。
- 请将测试程序当作 production code 的一部份，production code 中不该出现的坏味道，一样不该出现在测试程序中，尤其是重复的程序代码。所以测试程序，基本上也需要进行重构。但也请务必提醒自己，测试程序基本上不会包含逻辑，因为包含了逻辑，您就应该再写一段测试程序，来测这个测试程序是否符合预期。