一般的开发人员可能会认为验收测试只注重质量，但实际上，好的验收测试也意味着代码完成得更好，这也是软件测试工具供应商Typemock 的产品经理Gil Zilberfeld的观点。Zilberfeld表示，定义明确的验收测试能够提高代码的质量。他的测试驱动宇宙飞船讲习班就是专门用来训练开发人员如何做出更好的验收测试，参加这个讲习班还可以帮助项目经理完善验收测试，提高开发人员的工作效率。

Zilberfeld对这方面的话题比如敏捷以及测试驱动开发(TDD)有着非常积极的兴趣。他最常用来展示的就是他的测试驱动开发讲习班。讲习过程中，参与者登上遥远的太空之旅，这需要很多团队合作来完成复杂的工作从而生存下来。当然，他们并不会真的离开房间，不过，这样一个包含了推进装置、导航、救生以及武器装备的假想项目确实要比真实的场景更令人兴奋。开发人员也可以放下他们心里悬着的疑虑而投入到项目中，这一点很重要，因为两个小时的讲习其实包含了非常多的内容。

参与者两两分为一组，每一组都有一个特别的任务。以前Zilberfeld把他们分成更大的组，但是他发现团队活动占据的时间太多，而且团队活动只是整个任务的冰山一角。他表示，“将他们分为两两一组，可以让每个人全过程都专注于工作。”

所有的开发人员都要写出测试让搭档来进行编码。对于每一步，他们只有十分钟的时间想出大致的设计，十分钟来讲述他们与整个团队合作的过程。参与者很有可能会因粗心的设计而受到Zilberfeld温和的批评，他也会提出忠告“别看起来像是十分钟内胡乱拼凑在一起的。”

Gil Zilberfeld

不过Zilberfeld真的激发出了他们对于构建这种模型的思维和感觉。伴随着玩笑和批评的是最中肯、开放的问题：在这个过程中，参与者脑海里想的是什么。比如，他可能会问负责环境系统的开发人员(他们的工作部分严格禁止携带宠物上飞船)，“你是怎么想到蒸发的狗就是最好满足这一规定(“禁止携带狗”)的最佳办法的?” Zilberfeld还表示， “太空里经常会发生一些有趣的事情。”

在讲习课程中，开发人员要在飞行的时候要思考怎么进行代码测试，什么时候进行重构，以及如何平衡工作量等问题。为了模拟真实世界——开发人员几乎不会坐在一起，也不会以小组的形式工作，所以Zilberfeld要求他们不要互相交谈。这让工作变得更困难。

首先，Zilberfeld只是让开发人员来回传递代码。这就意味着他们的代码必须都很容易理解。他们不能就告诉搭档，变量“领导”就是指挥官的意思。要么给变量命名，让搭档看得很明显，要么在代码里加一句评论让搭档知道。然而，这只是产生误解的地方之一。

接下来，Zilberfeld看的不是开发人员的能力，而是测试的内容。他们必须知道测试的名称，但不一定要知道细节。只要清楚大的框架就行。到了这里，Zilberfeld开始说明给测试一个合适的描述名的重要性，他表示，“一个好的测试名称本身就是一种技能。而且这是大多数开发人员都能越来越熟练的技能。”

最坏的名字就像“测试一”，“测试二”等。另外，Zilberfeld看到很多程序员(尤其是Scala程序员)使用完整的句子来命名他们的测试。一开始，Zilberfeld对这些冗长的名字看不上眼，认为它们过长。但是不久，他就发现了这些长名字的潜在价值。他表示，“代码和文档名表达得越清楚，新手处理这些代码就越容易。这就意味着更高的可维持性。”

对于第三部分和最后一部分的测试，Zilberfeld让所有人更换搭档。那么，两人组中有一人至少了解了一半的代码(因为他/她自己刚写过)，而另一人是完全不知道的。而新搭档可能之前负责的是完全不同的工作内容，所以对当前的要求不是很了解。

现在，开发人员有机会对自己和他们项目目前的状态做一个简短的介绍，然后又回到零交流的状态，除了分享代码。这种情形下，很少出现权力之争。新搭档可能会对新的项目一筹莫展，工作成效也很有可能不如另一人。另一人也会感觉带新搭档上手进入状态可能会阻碍项目的进程。

他们如何应对这样的角色转换呢?每一组的答案都不一样。Zilberfeld表示，“忘记自己原来的角色就是最好的自省方式。”

这样的训练让开发人员从一个全新的视角来理解开发的过程。Zilberfeld说道，“你看人们解释他们周围发生的事情，他们在想些什么，你越需要去理解。” 在验收测试中首先构建这种理解，不仅可以测试软件有多好，实际上它从一开始就提升了代码的质量。

本文原载于电子杂志《数据价值十一月刊·数据可视化》。点击即可免费下载阅读。