使用 Go-Lookslike 测试数据形状

使用 Go-Lookslike 测试数据形状
作者Andrew Cholakian

我很荣幸向大家介绍我们在 Elastic 开发的一种新的开源 Go 测试/架构验证库。它的名字叫做 Lookslike。Lookslike 允许您以类似于 JSON 架构的方式与 Golang 数据结构形状进行匹配，但它比 JSON 更强大，与 Go 更为相似。它有很多在任何现有 Go 测试库中都不具备的功能。

让我们通过一个示例来直接看看它的功能：

// This library lets us check that a data-structure either similar to, or exactly like a certain schema.
// For example we could test whether a pet is a dog or a cat, using the code below.

// A dog named rover
rover := map[string]interface{}{"name": "rover", "barks": "often", "fur_length": "long"}
// A cat named pounce
pounce := map[string]interface{}{"name": "pounce", "meows": "often", "fur_length": "short

运行上面的代码将显示如下结果。

Checked rover, validation status true, errors: []
Checked pounce, validation status false, errors: [@Path 'barks': expected this key to be present @Path 'meows': unexpected field encountered during strict validation]

在这里，我们可以看到狗“rover”按预期那样匹配了，但猫“pounce”未按预期匹配，产生了两个错误。一个错误是未定义“barks”键；另一个错误是意外出现一个多余的键“meows”。

由于 Lookslike 通常是用于测试上下文中的，因此，我们开发了 testslike.Test帮助器，它可以生成格式良好的测试输出。您只需将上例中的最后几行改为下面显示的内容即可。

testslike.Test(t, dogValidator, rover)
testslike.Test(t, dogValidator, pounce)

复合

Lookslike 中的一个关键概念就是能够合并验证器。假设我们需要单独的 cat 和 dog 验证器，但又不想在每个验证器中重新定义像“name”和“fur_length”这样的通用字段。让我们来看看下面的示例是如何实现的。

pets := []map[string]interface{}{
    {"name": "rover", "barks": "often", "fur_length": "long"},
    {"name": "lucky", "barks": "rarely", "fur_length": "short"},
    {"name": "pounce", "meows": "often", "fur_length": "short"},
    {"name": "peanut", "meows": "rarely", "fur_length": "long"},
}

// We can see that all pets have the "fur_length" property, but that only cats meow, and dogs bark.
// We can concisely encode this in

为什么构建 Lookslike

Lookslike 源自 Elastic 的 Heartbeat项目。Heartbeat 是运行时间解决方案后面的代理，它会 ping 端点，然后报告端点是否在正常运行。Heartbeat 的最终输出是 Elasticsearch 文档，在 Golang 代码库中以“map string interface{}”类型表示。测试这些输出文档是创建这个库的需求所在，尽管现在它在 Beats 代码库的其他地方使用。

我们面临的挑战是：

• 有些字段的数据不需要精确匹配，例如“monitor.duration”，它用于计算执行所花的时间。它可能会在每次运行中产生不同的结果。我们需要一种方法来松散地匹配数据
• 在任何给定的测试中，很多字段与其他测试共享，只有少数字段是不同的。我们希望能够通过编写不同的字段定义来减少代码重复。
• 我们希望良好的测试输出能够针对各个字段失败分别显示一个错误，因此需要“testslike”测试帮助器。

鉴于这些挑战，我们做出了以下设计决策：

• 我们希望架构灵活，并且希望开发人员能够轻松地创建新的匹配器。
• 我们希望所有架构都是可组合和可嵌套的，这样，如果您在一个文档中嵌套了另一个文档，就可以合并架构而无需复制一堆代码了。
• 我们需要一个好的测试帮助器让测试失败易于读取。

主要类型

Lookslike 的体系结构解析两个主要类型：“Validator”和“IsDef”。“Validator”是编译给定架构的结果。它是一个接受任意数据结构并返回结果的函数。“IsDef”是用于匹配单个字段的类型。您可能想知道为什么它们之间有区别。事实上，我们将来可能会合并这两个类型。但是，主要原因是“IsDef”在文档结构中获取了关于其位置的额外参数，允许它基于该上下文执行高级验证。“Validator”函数不接收额外的上下文，但更便于用户执行（它们只接受“interface{}”并对其进行验证）。

有关编写自定义“IsDefs”的示例，只需参阅源文件即可。您可以将新的“IsDef”添加到自己的源来进行扩展。

现场示例

我们在 Beats 中大量使用了 Lookslike。通过此 github 搜索，可以找到大量用法示例。

我们需要您的帮助！

如果您对 Lookslike 感兴趣，请在 repo上提交拉取请求！我们可以特别使用一组更全面的“IsDef”。

---

想要更多了解Elastic技术，欢迎关注和报名参加webinar，近期安排如下：

2020年2月19日（星期三）15:00-16:00
使用Elastic Stack构建全方位可观察性实例

2020年2月26日（星期三）15:00-16:00
Kibana Lens 网络研讨会

2020年3月4日（星期三）15:00-16:00
Elastic Endpoint Security 概述网络

2020年3月11日（星期三）15:00-16:00
使用Elastic Stack监控网站资源