模糊断言

虽然经常有很好的“理由”来解释为什么我们不能写简单的断言，但是当你尝试了很多方式，可能会重新承认标准是一个非常好的主意。简单的断言有时候并不能满足所有的测试需求。

让我们看一下伪代码编写的一个单元测试测试用例：

// 这是伪代码
test('add new user to db' {
 
    user = createUser('John', 'Smith')
 
    id = system.addUser(user)
 
    readUser = system.retrieveUser(id)
 
    assert(user.firstName).is('John')
    assert(user.lastName).is('Smith')
});

上面具有简单测试的许多属性：

我们正在使用“John”和“Smith”的测试数据非常简单
作为API的被测系统适用于测试
我们使用精确的值来断言，这些值可以在测试之前进行预测
任何自动生成的内容（例如id以及userCreationDate（未显示））都不会影响我们的测试

但是

在上面的示例中，暗示可能为用户提供了id以及创建时间戳。

尝试编写这样的断言可能是一种诱惑

    readUser = system.retrieveUser(id)
 
    assert(user).is(expectedUser)

凡expectedUser莫名其妙地被设置为包含用户，将产生用户进行完全匹配。一般如果在测试中有一个构造对象称为“预期”，则通过这种方式进行断言的风险很高。
为了实现预测系统生成的事物的能力，我们最终不得不确保测试数据的唯一性。这可能很有价值，但是会产生大量的测试垃圾。

模糊匹配

// still a fictional language
    readUser = system.retrieveUser(id)
 
    assert(user).matches([
        { obj.firstName == 'John' },
        { obj.lastName == 'Smith' },
        { obj.id instanceof UUID },
        { obj.creationDate - now() < inSeconds(5) }
    ])

在此组合测试中，有一些具体的断言，然后有更多的模糊断言。

模糊匹配很麻烦

上面的解决方案显示了如何对对象类型，近似的对象值进行相对有意义的断言，甚至可以对字段的内容进行正则表达式匹配。它允许您断言无法预测的值，但是上面的断言之所以大，是因为我们正在对预期对象进行完全的匹配。

备择方案

在单独的测试中一次进行模糊匹配，一次只进行一次–避免整个对象进行模糊匹配
筛选出无法与比较数据匹配的字段
编写具有唯一性的属性以产生可预测的值
编写具有可预测的较低级别的测试，不必依赖较高级别的模糊匹配

结论

在断言中使用模糊匹配是一个好技巧，但是当没有其他方法可用时，它必须是最后的选择。更精确的字段匹配可以消除对模糊性的需求。

郑重声明：文章禁止第三方（腾讯云除外）转载、发表，事情原委测试窝，首页抄我七篇原创还拉黑，你们的良心不会痛吗？

模糊断言

但是

模糊匹配

模糊匹配很麻烦

备择方案

结论

技术类文章精选

非技术文章精选