四、如何才能做UT

       1.代码要首先可测，然后才能测。 首先要遵守契约式设计。类的每一个方法都应该对外承担了一份契约，有明确的前置条件和后置条件。 当你对这个方法进行测试之前必须清楚明白这两个条件。一个有效的方法一定是做了什么事的。一定会产生一定的影响，我们可以通过对外围环境的改变来检测方法产生的作用是否如预期(例如,获取某一对象的属性进行检测)。

       其次是，低Ce和单一责任原则。一个方法对外的依赖应该单一，不应该取决于很多的外部环境。因为不同的外部环境越多，组合项就越多，要测的先决条件就越多。而一个方法对外部环境的影响太多，则意味着职责不单一，对于输出越难测。

       曾经听有人讲到，这些道理，你懂了就懂，不懂就不懂，说了没用。但我认为，如果你还以为这些只是大道理，如果你还想对它有点切身的感受，做单元测试是一个很好的途径。

       2.信任你该信任的。

       对于已经稳定的部分，类似于第三方包，平台部分，其至是遗留系统中已经证明是可靠的部分，都可以信任。这些是我们用例代码依赖的部分，是我们用来检验其它待测部分的基石。如果什么都要测，就会变成什么都测不了。

       3. 单元测试要尽量少的增加开发人员的负担。

       一方面，我们实在被问题单压抑的太久了。所以，从全局上来看待这个问题，如果可以确实的减少后期的维护压力，对我们自身而言当然是有益的。所谓增加的负担，不过是提早了结了一些痛苦。

       另一方面，单元测试必须自动化 ，必须简单，傻瓜化。这是我们要努力的目标。

       4.将调试的时间用来写单元测试

       没有做过自动化单元测试的人永远也不能体会其给程序员带来的自信和好处。如果你还在调试，不如顺手加个测试。以后，保证同样的问题不会从你的眼皮下溜走。

       5. 现在的单元测试难在哪里？

       难以打桩。因为我们对其它模块的关联是这样的。

       这就是麻烦的所在，关联太多。如果我们要测，我们就要打桩。但是，

       1. 望而生畏，太多。

       2. 无法下手，都是直接对象依赖，而不是接口依赖。

       所以，你让我来测这样的代码，我是不会干的。

       因为，我希望的是这样的：

       但是，我们现在的代码欠债太多了。没有条件和能力再回去对这些代码进行单元测试。而且，这些功能经过这么多年的维护，大多已稳定。做的性价比也不高,不够实惠。所以，不必要做。

       但在新功能开发过程中，这些老代码依旧会如恶梦一样纠缠着我们。让写单元测试过程中常常面临着举步维艰的境地。我们不得不在让代码变得可测与对代码的侵入性测试之间进行抉择。