「原创声明：保留所有权利，禁止转载」
虽然经常有很好的 “理由” 来解释为什么我们不能写简单的断言，但是当你尝试了很多方式，可能会重新承认标准是一个非常好的主意。简单的断言有时候并不能满足所有的测试需求。
让我们看一下伪代码编写的一个单元测试测试用例：
// 这是伪代码
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) }
])
在此组合测试中，有一些具体的断言，然后有更多的模糊断言。
模糊匹配很麻烦
上面的解决方案显示了如何对对象类型，近似的对象值进行相对有意义的断言，甚至可以对字段的内容进行正则表达式匹配。它允许您断言无法预测的值，但是上面的断言之所以大，是因为我们正在对预期对象进行完全的匹配。
备择方案
- 在单独的测试中一次进行模糊匹配，一次只进行一次–避免整个对象进行模糊匹配
- 筛选出无法与比较数据匹配的字段
- 编写具有唯一性的属性以产生可预测的值
- 编写具有可预测的较低级别的测试，不必依赖较高级别的模糊匹配
结论
在断言中使用模糊匹配是一个好技巧，但是当没有其他方法可用时，它必须是最后的选择。更精确的字段匹配可以消除对模糊性的需求。
- 郑重声明：文章禁止第三方（腾讯云除外）转载、发表，事情原委测试窝，首页抄我七篇原创还拉黑，你们的良心不会痛吗？
技术类文章精选
- java 一行代码打印心形
- Linux 性能监控软件 netdata 中文汉化版
- 接口测试代码覆盖率（jacoco）方案分享
- 性能测试框架
- 如何在 Linux 命令行界面愉快进行性能测试
- 图解 HTTP 脑图
- 将 swagger 文档自动变成测试代码
- 五行代码构建静态博客
- 基于 java 的直线型接口测试框架初探
- JUnit 中用于 Selenium 测试的中实践
非技术文章精选
TesterHome 为用户提供「保留所有权利，禁止转载」的选项。
除非获得原作者的单独授权，任何第三方不得转载标注了「原创声明：保留所有权利，禁止转载」的内容，否则均视为侵权。
具体请参见TesterHome 知识产权保护协议。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
暂无回复。