这个版本真正将UT落实到项目中，工具是：JUnit＋EasyMock。来看看我们的UT之路：
阶段一
由于第一次使用EasyMock，看了几个例子，然后就在UT中应用它，一开始被它的几个例子误导了，下面是我们的测试方式：
1）对于一个接口定义下来后，就直接编码实现；
2）看着实现好的代码，针对每个逻辑分支，构造测试用例；
3）对于每个分支，先看看代码中该分支需要依赖哪个外部接口的哪个方法，方法需要哪些参数，然后就开始这些参数、Mock对象，并录制好Mock的预期行为，最后调用待测试接口，并对运行结果进行验收；
4）运行JUnit，看看Testcase是否执行通过，然后修改那些导致Testcase执行失败的代码，再执行用例。
这种测试方法执行了一段时间后，我们发现UT并没有发挥出人们一直吹捧的巨大威力，在我们这里好象只能起到代码检视的作用，发现的一般都是些小问题，并不能发现那些深层次的功能性问题，于是我们开始坐在一起反思。。。。。。
经过一顿海阔天空的胡撇，找到了原因：
虽然UT是白盒测试，但是我们这种方式却“白”的有点过头了，我们没有按照接口的功能去构造用例，而是在编码结束后再照着已经实现好的代码分支去构造用例，这时人的思维定势被固定在现有的实现中，失去了整体功能的把握，测试就失去了它的意义，无法发挥作用。
阶段二
在经过第一次的教训后，我们项目组内部定下了如下测试规则：
1）先确定接口的功能；
2）根据接口的功能构造所有的测试用例，每个测试用例的方法注释中写清楚该测试用例用于测试接口的场景，需要什么样的参数，接口执行的预期结果是什么；
3）编码，实现接口功能
4）补充测试用例的实现
5）执行测试用例
通过上面这种方式，真正的发挥了UT的作用，嗯，效果确实和人们吹捧的差不多，因为我们是从功能角度对代码进行测试的。
小心，不要雀跃于开发阶段的这种成就感上，后面还有个很深很深的坑等着你往里跳呢。创业难，守业更难。UT代码发挥的作用很有可能就止步于编码阶段，为什么呢？我自己发现这样一个现象：
在改问题单的时候，我改了接口中某个分支的实现，然后就拉起服务，登陆客户端进行验证，验证通过后，为了避免集成环境上的UT代码跑不通（可能是因为调用了依赖的外部接口的其它方法，或者需要修改参数等等），我会把相应的测试用例改到跑通，然后长长舒一口气，把所有代码（包括UT代码）checkin到服务器上，哈哈，打完收工。
问题出在哪里呢？代码出现问题，肯定是你的代码对于某些边界没有考虑到而导致的，也意味着你之前的UT代码没有覆盖到这个分支，OK，你现在把代码改正确了，并让以前构造的测试用例都跑通了，是件不错的事情，但你不为这个分支补充相应的用例，你如何保证后续的代码改动在这个分支上的处理是正确的呢？答案肯定是不能。在我看来，UT最最大的作用是它能保证你后续的问题修改、甚至于代码重构结果是正确的，是不会引入新问题的。
所以正确的做法是：
1）补充用例，并在用例的方法注释中写清楚该测试用例用于测试接口的场景，需要什么样的参数，接口执行的预期结果是什么；
2）修改接口实现，解决问题；
3）修改改动涉及的用例，并补充新添加用例的实现；
4）执行测试用例；
只有在所有测试用例都执行正确后，你才可以把代码放到环境中去验证。而且这样做也可以提高你的效率，因为你改完代码后就直接拿到运行环境中测试，首先得把服务器拉起，两三分钟过去了，然后再打开客户端登陆，ok又一分钟过去了，然后一测，发现没有验证通过，一看代码，靠！原来写错参数了。看是不是经常有这种现象呀^_^
说到这里，再额外提一点点。开发的还是比较喜欢编码，一个功能完成后，自己会即兴地测试几个正向用例，测试通过后，如果还有代码要写，他们就会赶紧 coding下去。在开发人员coding的过程中，测试人员会针对每个功能点设计测试用例，然后将测试用例发出给开发评审，这时即使开发人员很认真、很认真的去看看这些用例，但由于他们更喜欢Coding的癖好，顶多也就是回个检视意见而已，测试用例的作用也就仅限与此了，然后到了测试的时候，开发人员拿着之前的测试用例，可能就会发现某些测试用例和实际设计不一致，或者用例缺少。代码的质量不应该过于依赖测试人员，也不应该将测试推的太靠后，可能的下面的方式效果会更好些：
1）测试人员设计用例，并将用例发给相关的开发人员；
2）开发人员编码结束后，按照测试人员设计的用例进行功能测试，如果发现测试用例有问题则直接修改用例，对于缺少的用例则进行补充，在“开发者测试”完毕后，将更新完的测试用例反馈给测试人员；
3）对于没有进行“开发者测试”的功能，测试人员不予以验收测试；
通过“开发者测试”，将测试行动推前，应该更有利于质量的保证，也不会将问题堆积到迭代的后期，增加下一个迭代的风险。我们下个版本会进行尝试。
最后，要真正提高敏捷的效率，自动化测试是不可或缺的，通过自动化测试，可以大量减少手工测试的工作量，而且也更能进一步保证版本的质量，尤其在验证代码修改不会引入新的问题上可以起到重要作用。
相关阅读：
