单元测试也需要维护。在设计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>();
|
如果构造函数需要接受另外一种类型怎么办？或者删掉一个参数？我都得改测试。
所以我们做了一个API，用来解除构造函数定义和单元测试调用的耦合关系：
| var controller = Isolate.Fake.Dependencies |
这就完事了。Fake.DependenciesAPI会创建一个AnonymousCheckoutController类型的真实对象, 然后把所有依赖对象的伪造实现传进去，丝毫不涉及它们的类型。即便构造函数发生变化，测试依然工作。测试和代码之间的耦合变小了，也更容易读懂了。
更友好的测试
有写单元测试经验的人都知道，写测试是一种可以后天获取的技能。我们都能学会怎么把测试写好，但往往都是一路披荆斩棘。所以我们在考虑怎么让这个过程变得简单一些。怎样让别人避免重犯我们曾犯过的错呢？
这时候我们给Isolator引入了另一个功能。它可以检测测试，并在Visual Studio标记出常见的错误（例如测试中没有断言）。它同时还会给出修复的建议。
