测试场景具有指数级增长的结果

Question

真正吸引我TDD的一个原因是你的规范与实现的明确发展。

我正在寻求实现一个接受配置对象的构造函数

function MyConstructor(conf) {}

conf目前规定有两个键：a和b，其中a为RegExp，b为一个Function，作为我的TDD规范说明目标的一部分，我正在编写测试这个对象的测试：

• 如果MyConstructor不是Error或a不是RegExp，我希望b抛出Function。
如果配置中缺少MyConstructor或Error，则
• a会抛出b。

现在，我知道我可以将此行为封装在其他构造函数中，例如创建“配置”对象的Configuration构造函数。但是我现在看到的方式，无论这种行为最终在哪里，都必须将此行为封装在某处，以便通过TDD详细说明此规范。

问题是：在我看来，随着conf对象上的键数增加，测试次数也会增加 - 指数级！这尤其是由于上面的第二个子弹。

例如，假设我有4个键：a，b，c和d，我需要确保如果有任何错误，则错误是抛出。 似乎这需要我编写大量相同的平庸测试，涵盖所有可能性（组合！）以查找丢失的密钥。这听起来不对劲！然而，我无法想到明确或归纳地测试所有场景的好方法。有什么想法吗？

Answer 1

没有类定义或接口的对象很难测试。如果您的对象是 ducks ，则需要使用 ducktyping 进行检查。

您还可以想知道完全测试某些功能有多大用处。您可以测试边界，但永远不能测试所有值;

如果你的功能如下：

function sum(a, b) {
    if (a === 42) {
        throw new Error("All glory to the hypnotoad");
    }
    return a + b;
}

您希望如何找到此错误？

Answer 2

我建议您使用Duck Typing来强制执行这些类型。从本质上讲，你要做的就是按照你期望的那样使用你的密钥传入的对象，如果a不像RegEx或者你可以'，那么让JS运行时抱怨像函数一样调用b。