测试驱动开发（TDD）实践

4. 与用户沟通，明确需求

在开发代码的过程中，我们总会有遇到不太明确的需求点，这个时候和需求人员沟通那是必不可少的，了解了功能的输入和输出才能保证完美的完成任务。在沟通的过程中也加深了与客户的信任和默契度，不知不觉中还能提高EQ，一举两得。

5. 回归测试，确保新的更改不影响现有功能

在“韩梅梅”同学开发某个功能3个月后，“李雷”接到上级指示，客户要扩展该功能，但是原有功能保持不变。在苦心操劳了之后，“李雷”同学光荣的完成了任务，正准备接受大家赞誉时，“韩梅梅”跳出来向大家诉苦，那就是“李雷”为了做扩展功能把她之前做的功能给弄坏了，当时“李雷”那个心啊，拔凉拔凉的！

TDD的开发中加入了回归测试，这样就确保了之前的功能的正确与完整性，减少不必要的问题。

6. 提升系统的开放性和扩展性

一直以来我们做事都要讲先后顺序，软件开发也有着类似的工序。“李雷”和“韩梅梅”被一起“充军”到某紧急功能模块上，并且“李雷”要等“韩梅梅”完成她的功能模块才能开始自己的模块。为了解决这个问题，项目组决定使用某些技术来解除他们的依赖关系，比如使用到IOC以及一些设计模式，让他们能够同时开发，之后再将两人的功能模块组装到一起。

五．    TDD开发中需要使用到的技术知识点：单元测试、依赖注入框架和模拟对象

1. TDD的工作流

 TDD的工作流经常被描述为“红灯 -> 绿灯 -> 重构”：首先以一个未能通过的测试开始，随后编写足以通过该测试的代码，然后再重构代码。当然我们都不愿意看到不能通过的测试CASE，当你再继续编写项目代码，让原本不能通过的测试CASE通过的时候，你会感觉心里有一丝丝的惬意，然后再将代码优化重构，瞬间又有了些成就        感。抿一口水，工作就这么快乐的完成了。

2. 伪对象、依赖注入框（DI/IOC）与模拟框架

就最简单的实践来说，比较常见的三层架构，UI层去调用业务逻辑层，业务逻辑层去调用数据持久层。

“韩梅梅”做业务层的代码，“李雷”做数据层的代码，于是乎“韩梅梅”变成了“黄世仁”，“李雷”就成了“杨白劳”，其中辛酸只有“李雷”知道！为了改变命运，“李雷”决定做个“假”的数据层对象（模拟对象）给“韩梅梅”用着，省的她每天都在那催命。

(伪对象是对代替外部资源的简单模拟，它通常会在调用一个方法时为该方法返回预定义响应，但通常不会根据输入参数而改变响应。)

于是乎“李雷”欢乐的开始了他的计划，把“韩梅梅”所需要的功能点都用接口来实现（interface），然后把这接口的方法在单独的一个模拟类里面都只写了个简单的壳，里面的各种返回值都写成“韩梅梅”想要的数据样例，最后语重心长的对“韩梅梅”说：“东西拿走喜儿给我留下…”，“韩梅梅”当然是欢快的蹦到了自己的座位上。

(控制反转是对象在被创建的时候，由一个调控系统内所有对象的外界实体将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，这个责任的反转。)

“韩梅梅”拿到李雷给的伪对象后，径直就用了起来，在所有需要伪对象的类里面都直接用了万能的“New”关键字来实例化这个伪对象，这招兼顾了简单与实惠，广大程序员爱好者都爱这么干。

但是 “韩梅梅”后来慢慢意识到不太对，我有许多地方都用用到NEW字，那不是以后“李雷”完成了他所谓的真的对象以后，我还必须得改我的代码，把我之前放进去的伪对象给替换为真正的对象？我这不是自己给自己找茬么。

“韩梅梅”赶紧找到带着黑框身背双肩包的师兄，细说了当前的苦衷。黑框师兄那舍得是师妹这么忧愁，赶紧拿出杀手锏“控制反转”中的一招“依赖注入”，让使用类中仅保留被调用对象的接口，然后动态的注入实例给这接口，这样子只要实现了这个接口的类都可以被任意替换使用，并且这个注入的动作一般是由某个框架来实现的，比如Autofac,、Unity或者Ninject等等。

这下子“韩梅梅”心里踏实了，管你“李雷，张雷，王雷”写什么伪对象或者真的对象，只要你的对象实现了指定的接口，我都能使用，而且我还不用自己去手动创建这个对象，省心又省时。

（模拟框架是一系列用于快速创建伪对象的API，它能减少重复的代码，提高编码效率，比较常用的为Rhino, NSubstitute, Moq等。)

“李雷”和“韩梅梅”就这么和谐的合作，但是随着任务的增多，发现问题来咯：

1. “李雷”要手工做很多的伪对象给“韩梅梅”，任务繁重。
2. 每个对象的内部需求是不一样的，“李雷”发现要用一种通用的格式来创建这些伪对象几乎是不可能的。
3. 很多伪对象又依赖于其他的伪对象，这样子简直就是要让崩溃。
4. 很多为对象内部有状态需要保存，手动来写代码很难去维护这些状态标示。

 “李雷”好不容易通过创建伪对象来摆脱“韩梅梅”的每日请安，这又掉进了创建无数伪对象的漩涡之中。于是“李雷”横渡远洋，爬山涉水，期望能找到一盏明灯解决这些问题，终于功夫不负有心人，“李雷”找到了神兵利器去解决这个问题，那就是模拟框架。

模拟框架帮助“李雷”快速的创建了各种“韩梅梅”需要的模拟对象，以及各种所需的API，弹指一挥间，李雷用这神兵利器已经杀敌无数，嘴角不由得上扬了一番！

3. 重构代码

但是问题总归还是有得，她发现自己有些功能虽然测试通过，但是代码写的不好，经常被黑眼圈师兄批评，说她的代码质量不高。

所以她必须尽可能在刚测试通过之后就尽可能的优化代码，一来是少挨骂；二来也是提高自己编码水平的一个机会，查漏补缺；三是贵人多忘事，何况是“我这等如花似玉的姑娘！”，如果不及早优化，恐怕以后很难有时间再来弄了。

因为已经有了测试代码，所以重构代码那也是很有保障的事情，如果我改错东西了，那么我写的测试用例肯定不能通过，这样子也能让我信心满满的去把这些个有臭味的代码大卸八块了。

六．     工序流程

下面我们来看看“韩梅梅”和“李雷”他们的工作步骤：

1. 首先，韩梅梅和李雷分析了他们各自的业务，然后韩梅梅写出了她需要测试用例，里面尝试使用“李雷”将要提供的方法，并通过此方法获取数据。当然这些代码第一次是测试不通过的，因为里面需要的实现类还没有写。这里我们使用到Moq这样一个模拟框架。

测试用例的运行结果，大家也是知道的，两个字“悲催”！

2. 然后, “李雷”那边开始了数据持久层接口的编写(IProductRepository)，“韩梅梅”拿到李雷提供的接口后，完成了业务逻辑层(ProductService)的代码编写，完毕之后大吐一口气：“小伙子终于给力了一次！”。

• “李雷”的代码如下，实际上“李雷”只是提供了接口（interface）给“韩梅梅”，他还并没有开始编写具体的实现类，但是韩梅梅已经可以通过该接口来工作了。
• “韩梅梅”的服务类代码如下，她获取到“李雷”提供的数据持久层的接口后就开始欢快的编写代码，一切是那么的行云流水啊：

3. 接下来“韩梅梅”添加了各种需要的引用，再次运行起了测试用例，这次顺利的PASS了，心里那个激动，没的说！

4. 工作快要接近尾声，不过眼镜师兄提醒过“广大程序猿应该有高度的思想觉悟，不遗余力的提高代码质量”，为了达成这一目标，“韩梅梅”又开始了上跳下窜的“大家来找茬”。

她发现里面有段代码写的不好，循环太多，也不够整洁，她想优化下代码，又怕把写好逻辑弄坏了，不过现在有了测试用例，她不会再怕有这个问题，改错代码，测试用例自然也就无法通过。

再运行下测试用例，依然通过，此次代码优化完毕，如果还有新的问题可以在依葫芦画瓢的继续优化。    

5. 与此同时，“李雷”那边的数据持久层代码也差不多写好了，大家总得需要把代码合起来作“集成测试”，这个时候就要用到IOC框架来把“李雷”编写的数据层实例注入到业务逻辑层，注入实例使用的是Autofac这个IOC框架，我们这里使用构造函数注入，关于注入框架的更多信息，请读者G….gle。

至此，“韩梅梅”与“李雷”各自的工作都完成了，大家也不在互相说啥，各自都优化了各自的功能代码，快乐的工作继续进行着，我们的TDD讲解也到此结束！

参考文献：

1. Test Driven Development: By Example – Kent beck
2. Refactoring: Improving the Design of Existing Code – Kent beck
3. The Art of Unit Testing: With examples in .NET – Roy Osherove
4. Professional test driven development with C# - James Bender, Jeff McWherter