不写单元测试的厨师不是好司机

好吧，我认可题目就是个噱头，无聊的时候自娱自乐是一种病，得治！

今天要说的话题就是单元测试。从题目提及，厨师和司机都是很是常见的职业，在他们的职业生涯中有着各自的单元测试（其实单元测试无处不在，这里只是举一个简单的例子而已，请你们领会精神）。

菜桌上的每一道菜所经历的每一个步骤都有单元测试。从种菜开始菜的种子要通过精心挑选的必须成活率符合标准才会发放到各地的种子站。而后农民伯伯辛苦种菜拉到菜市场，到了菜市场想卖出去必须得有营业执照（不怕城管的好汉们除外）还得有卫生许可等等吧，每一步都是一个单元测试。相比而言那种自产自销的农家做业要么规模小要么质量达不到保证。

和司机有关的事物更是如此，每辆在马路上行驶的汽车它们的每一个螺丝钉都须要通过检验，最后车会被合格的部件组合到一块儿。司机的驾照也是一个“单元测试”，社会是复杂的不能让不安全的因素影响了其余人因此保证（或者说尽全力保证）每一个人的质量是保证整个社会交通安全的重要手段。

不仅仅这两个职业其余的一切一切都是这个道理，要想保证一个复杂的工程成功那么最有效的办法就是将这个工程分工，而后保证每一步每一部分都是成功的，如此一来这个复杂的事情就有可能会成功，这里仅仅是有可能而已，按照测试原理的说法就是，单元测试成功并不表明回归以及集成测试会成功。

因此这么说来单元测试是成功不可或缺的一步，是保证成功的重要一个环节。

几点要求：

• 每一个类都是应该能够被测试的，并且是容易被测试的。这就要求编码的时候要考虑单元测试，而不是单纯为了实现功能而实现功能。

• 单元测试覆盖率是应该保证的，边缘测试特殊值测试、以及条件分支的测试、异常捕获后处理的测试等等这些是保证覆盖率须要特别注意的地方。

• 若是用到了容器的东西，最著名的是EJB当中用到了服务器当中的东西，那么该如何测试呢，如今方法有两种，第一种是尽可能摆脱容器写可测试的类。第二种是创建模拟的容器，将容器中的东西模拟进去而且赋值，最终判断是否为预期输出。

单元测试每每进行是不顺利的，由于不少coder不会写单元测试更不会去考虑写单元测试的人的感觉，因此不少void返回值的方法、不少借用容器变量的方法遍及类中，致使测试困难。在测试这些方法的时候须要变通一下，好比最简单的就是测试list的add方法，返回值是void怎么办，能够放进去而后拿出来看看是否放了进去，也能够放进去以前看一下list的大小，而后放进去从新看一下大小。总之测试的意思就是代码有没有正常工做，不管是直接证实仍是间接的证实，只要你的理由充分的（或者必要的）那么这个测试就能够勉强说成是成功的。

目前为止单元测试没有提高到一个高度，由于从网上找一个单元测试的教程都找不到，找几本单元测试书都很困难。开发过程当中开发团队要么没有单元测试，要么就是仅仅是一个摆设，这就说明不多有人去关心单元测试，也说明单元测试仍是颇有难度的。后面几篇博客将详细介绍笔者在开发过程当中如何作单元测试的，但愿对读者有用。