UT、IT、BT之大成

最近看GEB，也取之大成。

我们构造软件就是在自己的梦里设计房子，它被设计成很美，可能是这个样子：

但是梦想最是离我们很遥远，因为你不是architect，你是Coder或者Junior Enginer。属于你的设计可能只是一面院墙，幸运地话可以拿到一个房间。设计一个房间，其实也不是简单地，对于拥有复杂繁琐开发流程的项目，你还是会面对相当是设计复杂性。各种需求文档、实现文档、设计文档。。。还有评审、修正。不得不说你是在做一个工程。手里的工具样样齐全。

现在我们来修一面墙，房间里其他三个面是别人修的，天花板准备成透明的，好看月亮，当然至少还有一扇门，可是它也不在我的这面墙上。我的工作就很简单了：拿起砖头，在下一层和砖头上涂上水泥浆，垒上去，锤实保证水平一致，如此反复，一层又一层继续，直到填满了整个墙面。

工作如此简单、只是些重复性劳动。这是这完全可以找个机器人来做，它最适合重复性繁琐劳动。但是为什么没有找个机器人来砌墙？这肯能可以用来解释为什么没有自动化的代码生成工具来完成简单繁复性代码的编写，实际上这是一个努力的方向，Apple正在简化APP开发的难度。

现在来看看这面墙，我们没有做更深入的工作，比如上灰、磨平、涂墙或者贴上墙纸。后面都人来完成这部分工作，这好比与UI Designer与开发人员。我们没有烧制砖头，因为砖头可以很便宜的买到。这就像基础函数、基础类型一样，我们完全不用关心它的内部实现。当然如果你修的墙上有扇门、或者窗子，就不得不求助于其他的人了（如果你既是砖工，又是木工，也不可能让你造出一扇门、一扇窗，项目的分工应该是明确的）。我们工作的核心就是涂水泥浆、垒转，这是一个拼凑的过程，写代码也是一样的。

看一个冒泡排序的例子：

public static void sort(int[]  values){
	int temp;
	for(int i=0 ; i < values.length ; ++i){
		for(int j=0; j <values.length - i - 1; ++j){
			if(values[j] > values[j + 1]){
				temp = values[j];
				values[j] = values[j + 1];
				values[j + 1] = temp;
			}
		 }
	}
}

所以的基本运算（赋值、判断、加减）都是Java语言赋予你的砖头，略加修饰就堆砌出冒泡排序这面墙，你所做的就是将它们有机地粘合在一起。

你肯定不想你修的这面墙质量不达标，被推倒重砌。因此我们需要对它做一些测试，这些测试便是UT。UT测试一个单元是否达到了你的设计预期。

有个UT之后，你能支持你的实现时符合设计的。但还没有完？这面墙和其他三个复杂另外三个面的人放到一起会是什么样？IT可以帮你验证。可以看到IT已经不是测试你一个人的功能领域了。

IT完成之后，已经验证了组件级别的设计实现是符合设计要求的。但整个系统级别呢？BT来完成它。随着测试级别的上升，对细节的了解关系已经不那么重要。BT用来验证需求是否得到满足。

这样一个顺序的测试验证过程类似于瀑布模型：

这样一个流程存在一个很大的问题就是，验证的速度非常慢，修改不能得到及时的验证。可以采用下面这样一个流程来进行改进：

每一个开发团队有自己的各级验证机制，验证的内容仅限于存在依赖或影响的需求领域，过多的测试内容使团队丢失了开发的本质工作。

当然这是一个权衡的过程。开发团队安排人做测试，会使开发速度下降。换来的却是质量的提升，越早发现质量缺陷越对项目有利。只要做好测试的快速测试（借助与自动化测试、良好的测试框架），这些投资完全是值得的。