
44
|
第
5
章
东西拼接了起来。给
Express
配置有关的中间件,然后启动服务。不用说要有效测试这些
代码有多困难,就说不必测试也是合理的理由,因为它只是把经过良好测试的代码装配起
来了。
甚至可以说,目前写的测试没多大用处,因为它们只是验证是否正确地配置了
Express
。
这次同样我也没法提供简单的答案。究竟要写多少测试?归根结底,你正在构建的应用类
型、你的经验层次,以及你团队的规模和配置,对此都会有很大的影响。我的建议是,与
其
不够
,还不如
多写
一点儿,这样随着经验的增长,就会知道多少才是“刚刚好”。
熵功能测试
熵
功能(带随机性的功能)测试有它自己的难点。我们可以为幸运饼的生成器再增加
一个测试,测试它的确返回了一个
随机的
幸运饼。可是如何知道某个东西是随机的
呢?一个办法是获取大量的幸运饼(响应),比如说
1000
个,然后衡量这些响应的分
布。如果这个生成器函数大体是随机的,那就说明没有哪个响应特别突出。这个办法
的不足之处在于它不是确定的。有可能(虽然实际不太可能)取到某个幸运饼的次数
是取到任何其他幸运饼次数的
10
倍,如果是这样,测试就会失败(取决于对“随机”
应该达到的样本容量阈值),然而这或许并不真的就说明所测试的系统失败了,这只是
熵系统测试的一种正常结果。在幸运饼生成器的例子中,生成
50
个幸运饼并期望其中
至少有
3
种不同的饼,可以认为是合理的。反过来说,如果我们是为某科学仿真或安
全组件开发一个随机源,就很可能希望进行更细致的测试。所以,测试熵功能是很困
难的,需要更多的思考。
5.8
集成测试