张大胖是鬼去个积极进取的程序员， 在日常工作之余，鬼去他还学习单元测试，鬼去重构等编程实践。鬼去

这一天晚上他看到微信群里在激烈地争论一个叫TDD的鬼去东西，不由地来了兴致，鬼去上网搜索了一下。鬼去

原来TDD就是鬼去Test Driven Development(测试驱动开发)，强调测试先行，鬼去小步快跑，鬼去用测试用例驱动出程序的鬼去接口和代码。

1

TDD步骤看起来异常简单：

1. 写一个失败的鬼去测试用例

2. 写一点代码，让这个测试通过

3. 重构代码(如果需要的鬼去话)，转到第一步

张大胖心想，鬼去这三个步骤不就是鬼去“把大象关到冰箱里”嘛，太抽象了! 一点儿都不实用!

他又搜了一些文章，发现这些文章中讲的都是一些极其简单的例子，如加减法计算器，货币转换等等。

比如这个计算器的例子，第一步先写一个简单的测试用例，服务器托管用来测试两个数字相加的行为。

public class CalculatorTest {      @Test     public void testAdd(){          Calculator calculator = new Calculator();         int result = calculator.add(10,20);         Assert.assertEquals(30, result);     }    } 

第二步在Calculator中实现add方法，完成两个数相加的逻辑，让测试通过。

public class Calculator{      public int add(int a, int b){          return a + b;     } } 

这个逻辑极其简单，就不用重构了。直接写下一个测试用例， 测试两个数字相减的行为。这样周而复始下去，直到所有功能都完成。

张大胖撇撇嘴：这就是TDD? 太没技术含量了，我明天就在项目中尝试一把!

2

第二天，张大胖看了一下自己的任务列表，里边有这么一个需求：

在下订单的时候，根据订单的金额，扣除优惠券，按照规则给用户增加相应积分

张大胖看了看这个计算规则，非常简单，估计一个函数就能搞定。

好，就拿你来试一试TDD这把刀吧，看看TDD到底有没有那么好，或者那么差。

第一步，先写一个失败的测试!

张大胖心中非常清楚，服务器租用这个系统用的是Spring，典型的Controller -> Service -> DAO。

在Controller中根本没有逻辑，就是调用Service而已。所以直接对Service层写单元测试吧， 张大胖很快就定位到这个新需求相关的类， 即OrderService的submit方法。

TDD本来是要驱动出接口的，现在看来不用了，已经存在了，张大胖看了一下接口的输入输出：

public class OrderService{      public String submit(String requestBody){          ......     } } 

这个方法的输入参数居然是一个XML字符串! 其中包含了像couponID, addressID这样的东西。

<createOrder>     .....     <addressID>xxxx</addressID>     <couponID>xxxx</couponID>     <paymentType>xxxx</paymentType>     ...... </createOrder> 

返回值也是一个XML字符串， 表示成功或者失败(以及对应的失败消息)。

<result>         <status>xxxx</status>     <msg>xxxx</msg> </result> 

这年头还用XML做参数，只能说这是一个老应用了!

3

按照TDD的节奏， 张大胖写下第一个测试用例，并且让它失败。亿华云计算

public void OrderServiceTest{      public void testBonusPoints(){                     String requestBody= ......;           //执行submit方法           String result  = orderService.submit( requestBody);                      ?? 验证积分， 可是怎么验证??     } } 

等一下，这个测试的输入参数容易构建，但是submit方法的返回值中根本就不会包含积分信息!那怎么才能我计算出的积分是正确的?

难道让submit方法返回积分数据?那就修改了本来是通用的接口协议，太不像话了!

第二个问题也很快浮现，积分计算的逻辑很简单，但是需要订单总金额和优惠券这两个信息，可是在测试用例中，这两个信息从哪里来?

订单总金额需要购物车，这是在数据库存放的，优惠券ID在submit方法的参数中，详情也在数据库中。

积分的计算这么简单，难道我还得先在数据库中创建一个购物车和优惠券，然后通过ShopCartService和CouponService从数据库读出来?这也太变态了吧?

不，单元测试一定要避开数据库，必须得用Mock的方式吧，张大胖知道一个Mock框架叫Mockito，挺好用的，就用它了。

张大胖又浏览了一下OrderService.submit这个长达2000多行的函数，这一看不打紧，张大胖发现这个函数依赖了另外七八个Service: UserService， ShopCartService, CouponService ......

这几个Service有的严重依赖数据库， 有的严重依赖Http ，有的依赖消息队列。

也就是说要想让submit方法顺利执行，必须得把这七八个Service都Mock出来，让它们能协调工作，例如：

给一个userID，就能返回一个正确的user对象。

给一个couponID，就能返回一个正确的coupon对象。

Mockito能实现这个功能，但是协调七八个个Service的相关对象，需要写出大量代码才行!测试用例中的代码会变得非常复杂、非常脆弱。

张大胖傻眼了 !自己连一个测试用例都写不出来，还搞什么TDD?

4

张大胖叹了一口气， 放弃了写测试用例的想法， 在OrderService.submit方法中，找到了合适的地方，然后根据订单金额和优惠券信息，写了几十行代码，把积分计算了出来，保存到数据库中。

然后启动程序，通过界面的方式提交了几个订单，涵盖了各种情况， 做了手工测试，然后检查数据库，他高兴地发现，积分计算完全正确，这才花了不到一个小时。

什么TDD， 让它见鬼去吧!

后记：

实际上真正的TDD并不是文章中那么简单的三个步骤， TDD正确的做法是根据需求先写粗粒度的功能测试，这些测试能驱动出程序的接口， 然后写细粒度的单元测试，驱动出细节代码。今天这篇文章实在太长了，就不展开了，再写一篇文章来讲吧。

理解了TDD的思路以后，改变思维，实施TDD并不是一件特别难的事情。

我这些年遇到的主要困难是遗留项目，代码很乱，可测试性很差，想写出清晰良好的测试，经常需要重构大量代码，这就得不偿失了，说是做TDD，其实大量的时间是在重构代码，开发进度缓慢，看不到立竿见影的好处，于是就放弃了。

【本文为专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

戳这里，看该作者更多好文