单元测试之大

现在，软件行业的人普遍都知道测试驱动开发，知道单元测试，尽管测试驱动开发在实践中存在一些争论，软件项目本身的一些约束条件或者开发人员的编程习惯都可能成为制约因素而不能真正做到100%的测试驱动、写程序先写单元测试。然而，必须承认对软件行业来说，单元测试的理念的确是一种进步，某种意义上说这是这个行业走向成熟的一种迹象。因为，在外界看来的高科技产业-软件行业，从发展程度来看，相当一部分企业及开发人员还停留在"手工作坊时代"的初级阶段：

问题1 - 软件产品质量的好坏主要由开发人员的"手艺"决定，并没有一种客观的可以量化的评测标准来衡量。
问题2 - 软件的变更甚或开发人员的更替都会导致软件质量某种程度上的不确定性。

单元测试的出现和流行使得这一现象开始有了改观，从管理的角度看它可以解决上述两个问题：

1.单元测试在软件的最底层发挥质量保证的作用
2.单元测试可以作为一种客观的质量评测标准，保证软件的质量的一至性

政治经济学中说 “生产工具和劳动者决定了生产力水品“ ，套用一下，单元测试的大规模应用可以标志着软件开发进入了"工业时代"。

单元测试之小

题外话：当今足球的先进理念，相信很多教练都知道，但是并不是每个人都能带领球队取得成功。米卢在中国成功了，杜伊最近的一些列战绩表明他正在走向成功，起码让人看到了成功地希望。

同样，知道单元测试，使用了单元测试并不一定代表你的软件开发水平真的提高了，误解及错误的应用反而适得其反。有一个相关的例子很知道玩味，PMP培训课上讲到质量管理的时候，强茂山老师举了一个例子，他说，现在很多公司都上了ISO质量体系认证，判断这个企业是不是真的实现了ISO的要求，一个最简单的方法就是看这个企业册成本在实施了ISO后是上升了还是下降了。

那么怎样的单元测试才是正确的，使之真正对软件开发起到正作用而不是一种负担？

单元测试原则：
1。 测试代码尽求简洁 - 单元测试的目的是检验被测试的代码(生产代码 Production Code)是否正确，复杂的测试代码，只会增加开发人员的工作负担 - 既要维护成产代码又要维护测试代码。

2。 测试代码要明确测试范围 - 范围(Scope)在软件行业中并不陌生，大到项目范围，小至一段测试代码的测试范围。单元测试，作为被测试代码的调用方(Caller, Consumer)，应该只关心被测试代码的公有方法及属性。因为：
a)被测试代码(生产代码)中只有其公有部分才会被外部代码调用，公有部分的测试通过即可保证被测试代码可以正常工作以供调用。

b)面向对象思想中有一个封装(Encapsulation)概念，封装使一个外部调用者只关心被调用着的公有接口，被调用者的内部实现的改变并不会影响外部调用者。只对成产代码的公有部分进行测试，使得测试代码易于维护，不会因为生产代码的内部实现(Private)的改变而被迫改变，这在一个复杂软件中尤为重要，维护测试代码不应该成为一种额外的负担。