单元测试实践总结报告
最近在部门内部推广单元测试，阶段性的总结总是免不了的。下面是这次单元测试总结的主要内容
1.单元测试所增加的工作负担
在开发阶段引入单元测试以后会增加一些工作量，有哪些工作量呢？
- 直接的单元测试开发的工作量。这部分的工作量是未使用的单元测试的开发过程所没有的。
- 由单元测试引发的设计变动、代码重构带来的工作量 。虽然，不管使用单元测试技术都会可以在开发、bugfix阶段 进行设计变动、代码重构等工作，但引入了单元测试以后，这样的行为会进行的更为频繁，当然带来的结果就是更好的设计、更易维护的代码，这个是我们所期望的，也是我们引入单元测试的目的之一。同样这部分工作也会带来一定的工作量。
- 对Bug进行单元测试补充的工作量。在不使用单元测试的情况下，遇到bug我们会直接调整生产代码，而运用TDD的项目中，我们鼓励的单元测试方法是
- 修改任何代码前先编写一个会失败的简短测试——即将出现的bug用一个单元测试用例来表达，当然由于bug的存在单元测试会失败。
- 然后再修改生产代码，使之前测试失败的单元测试通过，这就意味着这个bug被成功修复。
这种工作方式很有效，但的确会给Bug的修复又多一点带来工作量。 - 单元测试维护工作量。单元测试代码跟我们的生产代码一样需要好的设计和维护。当已有单元测试所支持的生产代码由于业务需求或者设计发生变动的时候，相应的单元测试代码也需要加以维护。
2.单元测试所减少的工作负担
在《1.单元测试工作量分析》中我们说的是单元测试带来的工作负担，但单元测试同样会给我们的开发过程带来效率的提高
- 提高开发效率。利用单元测试进行开发、bug修复的话，整个过程可以不依赖应用程序的容器，使得代码跟容易被运行。
- 减少重复工作，利用单元测试进行开发、bug修复的话，开发人员"反复录入测试数据、查看运行结果"的工作模式会单元测试自动运行的模式所替代。
- 减少Debug的时间。
单元测试还有很多优点，但还不会很直接的减少我们的工作负担
综合"1.单元测试所增加的工作负担"和"2.单元测试所减少的工作负担"提到的内容，虽然"1.单元测试所增加的工作负担"所增加的工作负担会被"2.单元测试所减少的工作负担"抵消掉一部分，但整体而言单元测试时会增加开发工作量的，会以牺牲time-to-market为代价。
3.如果看待单元测试增加的工作负担
由于我们增加了单元测试的开发工作，直接影响的是time-to-market的时间，所以大家一定会问以下这些内容：
- 单元测试开发实际增加的工作量是多少？
- 单元测试开发带来的好处整么体现？
第一个问题其实比较容易回答，只要大家通过一个实际的项目就能测算出来，我的感觉是单元测试所增加的工作负担会是原来的1/3，也就是说原本一个模块3天完成的，现在会变成4天。不过这只是我个人的计算。
第二个问题会比较难以回答。主要的原因有下面几个
- 单元测试所带来的价值很多时候是体现在软件的编码、设计、质量上门的，这些内容多数是软件的内在质量，跟软件的外在质量（完成了哪些功能、输入输出的验证做的好不好）不同难以被直接的发现和体验到。
- 如果单元测试的成果要体现在测试阶段的话，也需要涉及到QA本身的工作过程和模式，不能够直接体现在Bug Fix时间的减少，但一定可以减少bug数量等等。
分类: 测试驱动
