TDD系列1-从单元测试说起

    一个常见场景：项目开始，项目经理把需求拆解为若干个模块分发给不同的开发人员去完成。这样每个人可能只熟悉自己的那部分代码。当项目某个阶段开发完成并上线后，可能部分开发人员会离开项目进入别的新项目，留下个别人员继续维护；或者项目下阶段开发新进一大批人员并不熟悉当前项目；当然最常见的是，在修改BUG阶段是无法完全做到谁产生的BUG就安排谁去修改。这时候就会出现一种常见的情况：因为对当前代码要满足的各种目的不熟悉，在修改一个模块或者BUG的时候把原有正确的功能也影响到了！更要命的是，谁也不知道这个BUG出现了，等待测试人员需要去重新发现一遍。项目经理会发现，每次只要做了代码修改，无论是重构还是功能新增修改，还是修改了BUG，都无法知道当前代码的健壮性，以前编写的东西是否依然正确可用？
    这个问题的解决办法就是单元测试。

什么是单元测试

    单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
    单元测试目的就是用来验证代码的行为是否与我们期望的一致。

单元测试方法

1、分析软件需求文档，设计功能模块划分
2、根据功能模块设计出单元测试场景用例
3、编写单元测试代码
4、编写实际代码

单元测试优点

1、单元测试是一种验证行为。程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。
2、’单元测试是一种设计行为。编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。
3、单元测试是一种编写文档的行为。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
4、单元测试具有回归性，非常利于代码的重构。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

单元测试缺点

1、单元测测试增加了工作量。
2、需求变更时，测试代码和代码本身受同样的影响。

单元测试带来的挑战

1、单元测试改变了程序员的习惯，习惯的改变对任何人都是一种挑战。
2、单元测试同软件工程具有内在矛盾：需求分析和设计过程是自上而下的，典型过程是：模块分析–功能分析–表现层设计–数据（库）设计–控制层设计–服务层设计–DAO层设计；而单元测试构建则从小粒度开始，内在逻辑是自下而上；由此可见两者天生具有矛盾。如何解决这种矛盾对个人具有很大挑战性，对团队难度更大。
3、桩模块带来的难度：当采用单元测试时，绝大大多数单元都是要调用外部服务，如何提供外部服务方法官方的解决办法是用桩模块代替，但在实际实践过程中，桩模块代价非常大：构建装模块、桩模块替换、桩模块接口变化、外部服务同实现者理解差异等都给程序员带来很大工作量。

程序员对单元测试常见认识

1、 编写单元测试太花时间了
   简单事实是在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。 如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：
   1）对于所编写的代码，你在调试上面花了多少时间。
   2）对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。
   3）对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。
   回答完这些问题，你一定不再以“太花时间”作为拒绝单元测试的借口。
2、 运行测试的时间太长了
   合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。 　　
3、 测试代码并不是我的工作
   你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。 　　
4、 我并不清楚代码的行为，所以也就无从测试
   如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢? 　　
5、 但是这些代码都能够编译通过
   我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。 　　
6、 公司请我来是为了写代码，而不是写测试
   公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。 　　
7、 如果我让测试员或者QA（Quality Assurance）人员没有工作，那么我会觉得很内疚
   你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。 　　
8、 公司并不会让我在真实系统中运行单元测试
   我们所讨论的只是针对开发者的单元测试。也就是说，如果你可以在其他的环境下（例如在正式的产品系统中）运行这些测试的话，那么它们就不再是单元测试，而是其他类型的测试了。实际上，你可以在你的本机运行单元测试，使用你自己的数据库，或者使用mock 对象。

   无论如何，当我们清楚了单元测试好处与缺点，知道将面临的挑战，最终下定决心要使用，那如何去实践呢？个人认为单元测试的最佳实践是TDD，请看“认识TDD"