如何使用单元测试改善代码质量？

    我们经常说没有经过测试的代码是不能交付的。项目测试阶段，从开发部门交付给测试部门，项目上线时，从开发部门交付给运维部门，项目运行时，从开发部门交付给用户，基本上从代码编写第一行开始，开发部门就面对一个问题，代码是否可以交付，交付给谁？交付前，你是否有把握确定自己的代码质量已经达标。

    代码开发是什么？Robert C. Martin在经典著作“敏捷软件开发：原则、模式与实践”中，引用了一篇来自Jack W. Reecves论文(1992)——“软件设计”（详文参见书中的附录D），进行了明确阐述：源代码就是设计。这个观点，我非常认同。这个观点不是说软件设计就是代码开发，而是说代码开发是软件设计的一种。代码开发，就如同设计文档，架构图，样例模型一样，都是设计，只不过是最底层的设计，最贴近交付物的设计。既然是设计，就需要评估，审核，但是在实际操作过程中，我们有各种各样的文档评审，但是对于源代码级的评审，就做的不是特别好，通常都是开发人员自己做一些简单的代码级测试就完成了，测试用例少，组织性差，根本达不到代码评审的效果，那就更谈不善对质量的改善。

    

    在代码没有交付前，开发人员自己编写的一些测试脚本，完成的源码级测试，我们叫做单元测试。这种测试主要目的是为了校验开发人员所编写的代码(单元模块)是否能够运行正常。还有一个附加效果，也是展示了该单元模块的API实现是否能够体现架构设计意图。单元测试用例必须编写，因为测试用例就是对源码的讨论和评审。没有经过讨论或者评审的文档，你不敢发出去，那么没有单元测试用例保障的源代码也是不能被认可的。所以我们首先要做的就是对自己的代码进行单元测试用例编写。

    单元测试用例全部运行完毕后，我们需要汇总结果，给出覆盖率说明。然后每次bug修复，重构优化，以及新功能加入，都需要重新运行，以保证代码的稳定性。随着开发人员的编码继续深入，原来写的测试用例代码可能就会运行失败，开发人员就需要调整测试用例，这个工作量会越来越大。这个编码，运行测试代码，再修改过程在整个过程中需要反反复复，而且很机械，所以我们可以借用一些工具来协助：Maven，Jenkins，JUnit，Surefire，Cobertura，ClearCase。

    1)Maven，超赞的项目管理工具，编译，打包，部署，一条龙服务。

    2)Jenkins，CI工具，可以作为daily-build使用

    3)JUnit，SureFire，Cobertura，单元测试，测试覆盖率检查工具。

    4)ClearCase,IBM的商业化版本管理工具    

    

    一个软件项目单元测试用例可以按照如下的模式进行管理：

    1）由技术管理者(架构师/技术经理/高级程序员)编写模块间的交互集成接口，并完成集成模块的测试代码编写，并用JUnit测试通过后，提交CC。

    2）每个小组编写自己负责单元的代码和测试用例，并用JUnit测试通过后，将源码和猜测代码都提交CC。

    3）Jenkins从CC上获取最新代码，调用Maven工具，进行编译，打包。

    4）Jenkins利用Maven测试命令，调用SureFire，Cobertura插件完成所有测试用例的运行，和覆盖率检查，用以查看代码集成后的效果。

    5）根据测试输出结果，修复和优化代码。

 

    通过工具，我们减轻了很多繁琐的工作：统一的编译，打包，批量测试用例运行，给出运行报告。对于开发者来说，可以集中精力在代码设计上和测试用例的维护上。

    当然有了工具可以极大的降低我们的测试成本，但是在测试用例的维护上，我们需要了解一些常识，以免走太多的弯路：   

    1）跨模块的交互接口设计要少，尽量做到模块独立。

    2）跨模块的代码肯定系统的设计核心，测试用例代码尽可能先设计，用以确定各模块配合的接口和数据传递方式。

    3）跨模块的代码是系统架构设计的重要体现，所以除非重大设计缺陷，尽可能不要去更改这部分对的测试用例，当然这也要求了刚开始的设计可扩展性。

    4）核心数据结构需要提前设计出来，这些数据结构要相互独立，在交互结构上尽可能使用这些核心数据结构，这样可以避免暴露模块内部自身特有的数据结构。核心数据结构的变更，必需保证测试用例同步更新。

 

   在修复测试结果上，也有些基本原则需要遵守：

    1）每次bug的修改，尽量做到只修改一个地方，修改结束后，要及时运行测试检查。

    2）要避免修改bug演变为修改设计的风险。除非有充足的理由让你这么做。

    3）测试用例要设计的足够仔细，足够多，测试用例没有检查出来的代码问题，就不要立即去优化代码算法。

    4）代码的重构，优化，一定是在所有bug修复结束后，才开始的。如果对新功能的开发不能带来实质性的改进，那么重构和优化可以继续延后。

 

    单元测试确认后的代码，在结构上，扩展上，稳定上都能够达到系统的设计要求，此时再对外进行交付，应该是合格的，质量比较好的。单元测试是可以通过工具不断的重复执行的，所以发现错误几率高——随时可以运行测试用例，耗用成本低——投入的人力和设备都比较少，在这个时候把单元测试做好，能够极大减轻后续阶段的工作压力。所以在代码编写时，就同时完成单元测试用例的编写，代码量似乎增加很多，但是对于项目整体而言，这些投入还是相当值得的。