解决真实世界的单元测试问题

作者：网络转载发布时间：[ 2012/11/2 9:39:12 ] 推荐标签：

　　单元测试也需要维护。在设计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标记出常见的错误（例如测试中没有断言）。它同时还会给出修复的建议。