单元测试也需要维护。在设计API的时候我们也考虑了这一点。举个例子看看,下面是一个对象的构造函数(出自一个叫做ERPStore的开源项目):

public AnonymousCheckoutController(
         ISalesService salesService
         , ICartService cartService
         , IAccountService accountService
         , IEmailerService emailerService
         , IDocumentService documentService
         , ICacheService cacheService
         , IAddressService addressService
         , CryptoService cryptoService
         , IIncentiveService IncentiveService)

  它的参数很多。在测试里我可能需要伪造这些依赖:

var fakeSalesService = Isolate.Fake.Instance<SalesController>();
var fakeCartService = Isolate.Fake.Instance<ICartService>();
var fakeAccountService = Isolate.Fake.Instance<IAccountService>();
var fakeEmailerService = Isolate.Fake.Instance<IEmailerService>();
var fakeDocumentService= Isolate.Fake.Instance<IDocumentService>();
var fakeCacheService = Isolate.Fake.Instance<ICacheService>();
var fakeAddressService = Isolate.Fake.Instance<IAddressService>();
var fakeCryptoService = Isolate.Fake.Instance<CryptoService>();
var fakeIncentiveService = Isolate.Fake.Instance<IncentiveService>();


var controller = new AnonymousCheckoutController(
    fakeSalesService,
    fakeCartService,
    fakeAccountService,
    fakeEmailerService,
    fakeDocumentService,
    fakeCacheService,
    fakeAddressService,
    fakeCryptoService,
    fakeIncentiveService);

  如果构造函数需要接受另外一种类型怎么办?或者删掉一个参数?我都得改测试。

  所以我们做了一个API,用来解除构造函数定义和单元测试调用的耦合关系:

var controller = Isolate.Fake.Dependencies();

  这完事了。Fake.DependenciesAPI会创建一个AnonymousCheckoutController类型的真实对象, 然后把所有依赖对象的伪造实现传进去,丝毫不涉及它们的类型。即便构造函数发生变化,测试依然工作。测试和代码之间的耦合变小了,也更容易读懂了。

  更友好的测试

  有写单元测试经验的人都知道,写测试是一种可以后天获取的技能。我们都能学会怎么把测试写好,但往往都是一路披荆斩棘。所以我们在考虑怎么让这个过程变得简单一些。怎样让别人避免重犯我们曾犯过的错呢?

  这时候我们给Isolator引入了另一个功能。它可以检测测试,并在Visual Studio标记出常见的错误(例如测试中没有断言)。它同时还会给出修复的建议。