学习单元测试的点点滴滴

测试的概念确实比较广泛,robbin说的是取决于用户的理解层次的.

我们的用户看重的并不是代码级的单元测试，
对于我们一个单据流转类型的项目举例，
客户要求如下：
1、可以在运行环境中随时发起一个测试单据，该单据在任何流程节点必须以醒目的方式标识为“测试单”，并且不纳入正式统计报表中。该测试单应当可以删除
2、对于所有接口，要求接口双方必须提供单独的接口测试工具，用以对双方接口进行测试
3、对于异常引起的垃圾数据，必须有手段可以提示并且清除（可以是人工清除，但必须有详尽的说明）

我们做了以后才发现，以上三点的成本如果在早期加以考虑，成本相对还可以接受，但是在后期功能基本完成的情况下加以考虑，成本极其高，因为基本牵涉到每一个模块的变更。

量化的数字没有，但是标准是有的：就是测试必须能够以最小的代价（最好是无人值守）自动、反复运行；测试的结果只有两个：成功或失败。

反复运行的标准其实意味着，测试的运行应该不依赖环境，比如数据库、文件、网络、对象容器、web容器、ejb容器等。任何时候运行测试，结果应该是一样的，而不是环境不同，结果不同。一旦环境准备的代价太高，就不会有人去做单元测试了。

没有经验的程序员写的单元测试往往选取的测试目标粒度过大，当然这跟设计也有很大关系。当一个方法太大，测试也会难以维护。更重要的，当这个大方法访问了数据库，而持久化的逻辑并没有被良好的隔离的话，它的测试程序就很难做到不依赖数据库环境，进而，它就很难做到反复运行。到最后，测试就变成了摆设。

单元测试既然叫单元测试，就一定是白盒测试，针对的是“单元”，在Java里就是一个一个的方法，而“白盒”是相对于整个系统而言的，换个角度看，单元测试又会把要测试的方法看成是黑盒，要测试的仅仅是对于给定的输入是不是得到期望的输出。

而功能测试当然与此不同，是站在操作者的位置上使用系统，把系统当作黑盒，给输入，看输出是否是期望的内容。功能测试一样需要自动化，尤其对于大规模的系统，不过功能测试自动化的代价要比单元测试自动化的代价要高的多。

功能测试是对系统边界的测试，而单元测试是对方法边界的测试。方法的边界其实就是API接口，系统的边界就是用户界面、网络协议等。

单元测试和功能测试的角度不同，它们当然是不可以相互替代的。

单元测试的白盒黑盒之说取决于哲学倾向.估计哪个或者混起来的都没错。从面向接口编程的角度来说，测试的只是接口的契约，当然是越黑越好；但从算法本身导致的隐错而言，当然是白盒才能发现。郁闷....
而且，更恶心的是，还有人把单元测试分为逻辑单元测试、集成单元测试、功能单元测试，虽然我赞同单元测试的这个内涵，但是仍然觉得非常恶心。

单元测试如果把方法当作白盒去测试的话，就违背了测试API契约的原则，换一个角度想，应该是设计有问题，可能是方法的粒度过大，也可能是分支过多。好的OO设计，代码中的分支应该越少越好，分支的多少可以从一个侧面去衡量设计的好坏（当然不是唯一标准，而且也不可能做到一个分支也没有）。异常机制从某种程度上缓解了条件判断的需要，它可以将分支变为优雅的、更贴近自然语言的try-catch-throws。

对于测试来讲，如果还在想将被测试方法看成白盒去考察代码覆盖，只能说明你的思想还停留在面向过程设计的时代。测试不需要了解方法的内部实现，目标只有一个，就是API契约。

以前我是一个契约测试的双手双脚赞同者，因为我以前喜欢中等粒度设计先行。现在么，有那么一点点怀疑。
如果从TDD的做法来看，最早的时候是没有接口的。接口是浮现出来的，阿门.  或者说，接口是某个过程的产物，但是测试却是这个过程能够顺利走下来的保障。
还有一个，对于测试用例的选择，不了解一点点白色信息，还是有点难。尤其是边界值的测试，一般而言，程序中的错误中至少有25%和这个有关，但是边界值是完完全全白盒里面的东西。我怎么能放任不管？

charon说的有理。

我觉得用单元测试来作为加钱的砝码是不现实的。

如果是国内常见的项目，提交给最终客户只是最后的系统，甚至服务器都是放在公司，客户只是关心功能，源代码都不要了，那么交付单元测试就无从谈起，用户并不会为此多付钱。反而如果能够提供的测试功能模块，辅助的高级用户（就是那些单位，公司的IT部门维护人员）进行一些初级故障原因测试，那么这个反而可以向用户多收钱。

如果是外包型项目，或者平台型，引擎之类的项目，客户也是开发人员，需要进行灰箱或者白箱应用的，那么单元测试就是绝对必要的，这个时候，却又无来加钱之说，因为没有单元测试，根本其实就不能收货。

题外话：所以我向来不鼓励使用没有带单元测试的开源代码，一来是没有足够的地方看各个类的详细使用方法（虽然良好的API文档可以代替）二来是修改和重构根本无从谈起，这个也是我讨厌shark的原因，因为它的src不带unit test，不知道是我没细心找，还是单元测试是另外下载，不和源代码一起的。

看了以上的讨论，有一个倾向明显浮现出来，对开发方而言，做单元测试一定比不做要高成本。

如果这是事实，那么这个这高成本是在短期里体现出来，还是在长期里体现，还是无论长短期都是如此呢？  如果它在短期里体现，是不是说，在这段时间里，做UT的团队就很惨？他们可能接不到单，可能被上级骂，可能被反对以至被解散？  若是在长期体现高成本，那UT估计就没戏了。

最后，如果做UT比不做要低成本的。那到底是什么让我们没有做UT？是因为不知道？是因为不会做？是因为不让做？

一堆的问题后，其实我心中是有答案的。我做的和所能做的就是让多一些同事了解UT的价值，让有权决定做不做UT的人决定做UT。当然，某天若然有那样政策也不错，但是执行得怎样就难说了。

单元测试如果不需要讨论做不做。需要讨论的是单元测试怎么做。
在单元测试进行之前，首先要有一个好的代码规范。否则，单元测试也不过是走走形式罢了。如果一个方法就有3000行代码，怎么单元测试也不会有用处。
一个很重要的规范就是，单个方法不得超过25行，特殊情况需要项目经理审批(一般是对字段较多的类赋值)，达不到这个标准的程序员一律淘汰。
其他还有不允许在单个方法中存在嵌套的控制语句。不允许两个以上的方法控制同一个状态。不允许存在没有注释方法，不允许变量命名少于三个字母(循环变量i除外),不允许使用循环变量j等等(特殊情况报项目经理审批等等)。
最重要的还是，使用优秀的程序员。一点设计能力都没有的程序员，是项目的累赘。