虽然经常有很好的“理由”来解释为什么我们不能写简单的断言，但是当你尝试了很多方式，可能会重新承认标准是一个非常好的主意。简单的断言有时候并不能满足所有的测试需求。
让我们看一下伪代码编写的一个单元测试测试用例：
代码语言：javascript复制// 这是伪代码
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以及创建时间戳。
尝试编写这样的断言可能是一种诱惑
代码语言：javascript复制 readUser = system.retrieveUser(id)
assert(user).is(expectedUser)凡expectedUser莫名其妙地被设置为包含用户，将产生用户进行完全匹配。一般如果在测试中有一个构造对象称为“预期”，则通过这种方式进行断言的风险很高。为了实现预测系统生成的事物的能力，我们最终不得不确保测试数据的唯一性。这可能很有价值，但是会产生大量的测试垃圾。
模糊匹配
代码语言：javascript复制// 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) }
])在此组合测试中，有一些具体的断言，然后有更多的模糊断言。
模糊匹配很麻烦
上面的解决方案显示了如何对对象类型，近似的对象值进行相对有意义的断言，甚至可以对字段的内容进行正则表达式匹配。它允许您断言无法预测的值，但是上面的断言之所以大，是因为我们正在对预期对象进行完全的匹配。
备择方案
- 在单独的测试中一次进行模糊匹配，一次只进行一次–避免整个对象进行模糊匹配
- 筛选出无法与比较数据匹配的字段
- 编写具有唯一性的属性以产生可预测的值
- 编写具有可预测的较低级别的测试，不必依赖较高级别的模糊匹配
结论
在断言中使用模糊匹配是一个好技巧，但是当没有其他方法可用时，它必须是最后的选择。更精确的字段匹配可以消除对模糊性的需求。
- 郑重声明：文章禁止第三方（腾讯云除外）转载、发表，事情原委测试窝，首页抄我七篇原创还拉黑，你们的良心不会痛吗？
