你可能觉得折腾这么一套东西动作也挺大的。我得说,“看菜吃饭”。
另一个例子,有一个测试框架,万事俱备,就是没法把test case自动传送到Apple Macintosh的机器上。现有的代码可以让test case在Apple Macintosh上执行,也可以把test case从服务器下载到Windows测试机器上发动执行,但是没法跟Apple Macintosh交流。
怎么办?在Apple上开发谁都不懂。在Apple Macintosh上写一个客户端跟服务器交流,够忙半天的了。面对一整套已经完备的测试框架,让它尽快用于新的环境,比做什么都重要。
别人告诉我,可以Apple Macintosh上开一个共享夹,然后Windows的机器可以用UNC路径往里面读写文件。
OK,这就足够了。Windows测试机器上发动执行的只是一个脚本,把需要用到的文件往指定Apple机器的共享文件夹上写。写完之后再写一个文件,名字是约定好的,例如“ready”,里面包含启动test case的命令行。然后不停的隔一段时间检查共享文件夹里面一个叫做例如“done”的文件,出现之后把它作为结果返回服务器,最后把它和其它文件都删掉,退出。
Apple Macintosh上面则运行另一个脚本,始终不退出。它不停的隔一段时间检查其指定的共享文件夹里面一个叫做“ready”的文件,出现之后执行里面的命令并且等待它结束。这个命令必须生成一个叫做“done”的文件,包含执行结果。然后,不停的隔一段时间检查“done”是不是还在,不在了就回到最初的检查“ready”的代码。
这就足够了。两个脚本加起来50行不到。
你觉得它太粗糙了吧?这么简单的协议?
事实上,它并不需要十分健壮。
一、 Windows和Macintosh双方的网络文件系统协议解决了很多问题
二、 测试机器是不会有人去用的,你可以安全的假设只有你的程序在执行
三、 服务器和test case都已经测试过,他们应该负担起若干健壮性的需求。事实上,他们比这两个脚本更适合做这个,不是吗?
这就是“看菜吃饭”:不需要的功能,是不需要去实现的,无论它看上去有多么的cool;必需的功能,无论如何都要做到,无论它看上去有多么的boring。
其实,无论开发测试,都是为了让人们更好的发挥自身的潜力。开发工程师让人们可以专注于自身的事业而不用过多学习计算机技术;测试工程师让开发工程师可以发挥自身开发的潜力而不用过多参与质量保证的事务。代码高下之分,只能通过让人们发挥了多少潜力来检验。
《神雕侠侣》里提到独孤求败晚年“飞花摘叶皆可伤人”,皆因“不滞于物”,达到“无剑胜有剑”的境界。
所以,开发和测试工程师写出来的代码高下之分,对于这个问题,我会这样回答:皆可伤人,何须理会是花叶还是刀剑;都能发挥人们的潜力,不必关心来自开发还是测试的手笔;优劣之分,或者只来自于用剑者本身。