虽然经常有很好的 “理由” 来解释为什么我们不能写简单的断言，但是当你尝试了很多方式，可能会重新承认标准是一个非常好的主意。简单的断言有时候并不能满足所有的测试需求。
让我们看一下伪代码编写的一个单元测试测试用例：
// 这是伪代码
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')
});
上面具有简单测试的许多属性：
在上面的示例中，暗示可能为用户提供了 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) }
])
在此组合测试中，有一些具体的断言，然后有更多的模糊断言。
上面的解决方案显示了如何对对象类型，近似的对象值进行相对有意义的断言，甚至可以对字段的内容进行正则表达式匹配。它允许您断言无法预测的值，但是上面的断言之所以大，是因为我们正在对预期对象进行完全的匹配。
在断言中使用模糊匹配是一个好技巧，但是当没有其他方法可用时，它必须是最后的选择。更精确的字段匹配可以消除对模糊性的需求。
