最简单的单元测试方法针对 influxdb 查询是什么？

本篇文章向大家介绍《最简单的单元测试方法针对 influxdb 查询是什么？》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

我有一项仅对 influxDB 进行查询（读/写）的服务。

我想对此进行单元测试，但我不知道该怎么做，我读过很多关于模拟的教程。很多涉及像 go-sqlmock 这样的组件。但由于我使用的是 influxDB，所以无法使用它。

我还发现我尝试使用的其他组件（例如 goMock 或 testify）过于复杂。

我认为要做的是创建一个存储库层，一个应该实现我运行/测试所需的所有方法的接口，并通过依赖注入传递具体类。

我认为这可行，但这是最简单的方法吗？

我认为到处都有存储库，即使对于小型服务，只是为了它们可测试，似乎是过度设计的。

如果需要，我可以给你代码，但我认为我的问题有点理论性多于实际性。这是模拟自定义数据库以进行单元测试的最简单方法。

解决方案

根据其定义，如果您使用外部资源测试集成，我们谈论的是集成测试，而不是单元测试。所以我们这里有两个问题需要解决。

单元测试

您通常做的是拥有一个接受接口的数据访问层，这反过来又很容易模拟，并且您可以对应用程序逻辑进行单元测试。

package main

import (
    "errors"
    "fmt"
)

var (
    values   = map[string]string{"foo": "bar", "bar": "baz"}
    Expected = errors.New("Expected error")
)

type Getter interface {
    Get(name string) (string, error)
}

// ErrorGetter implements Getter and always returns an error to test the error handling code of the caller.
// ofc, you could (and prolly should) use some mocking here in order to be able to test various other cases
type ErrorGetter struct{}

func (e ErrorGetter) Get(name string) (string, error) {
    return "", Expected
}

// MapGetter implements Getter and uses a map as its datasource.
// Here you can see that you actually get an advantage: you decouple your logic from the data source,
// making refactoring (and debugging) **much** easier WTSHTF.
type MapGetter struct {
    data map[string]string
}

func (m MapGetter) Get(name string) (string, error) {
    if v, ok := m.data[name]; ok {
        return v, nil
    }

    return "", fmt.Errorf("No value found for %s", name)
}

type retriever struct {
    g Getter
}

func (r retriever) retrieve(name string) (string, error) {
    return r.g.Get(name)

}

func main() {
    // Assume this is test code. No tests possible on playground ;)
    bad := retriever{g: ErrorGetter{}}
    s, err := bad.retrieve("baz")
    if s != "" || err == nil {
        panic("Something went seriously wrong")
    }

    // Needs to fail as well, as "baz" is not in values
    good := retriever{g: MapGetter{values}}
    s, err = good.retrieve("baz")
    if s != "" || err == nil {
        panic("Something went seriously wrong")
    }

    s, err = good.retrieve("foo")

    if s != "bar" || err != nil {
        panic("Something went seriously wrong")
    }
}

在上面的示例中，我实际上必须实现两个 getter 来覆盖所有测试用例，因为我无法使用模拟库，但您明白了。

至于过度工程：简单明了，不，那不是过度工程。这就是我个人所说的正确的工艺。从长远来看，习惯它是值得的。也许不是在这个项目中，而是在未来的一个项目中。

集成测试

狡猾的。我倾向于做的是确保我的查询在提交之前是正确的;)

在极少数情况下，我真的想在 ci 中验证我的查询，例如，我通常创建一个 makefile，它反过来启动一个 docker(-compose)，它提供我想要集成的内容，然后运行测试.

扩展@markus w mahlberg 的答案：

如果目标是验证查询是否有效并针对流入实际执行，则没有针对流入实际执行这些查询的快捷方式。这些通常被认为是“集成”测试。我发现使用 docker-compose，这些测试可以与单元测试一样可靠，并且足够快，可以集成到 ci 中。在 ci 中执行测试使本地工程师能够轻松运行这些测试来验证他们的查询更改。

我认为到处都有存储库，即使对于小型服务，只是为了它们可测试，似乎是过度设计的。

我发现这是一个相当两极分化的讨论。 test implementation IS a concrete implementation 为 reliable, repeatable tests 铺平了道路，支持轻松隔离和执行代码的特定组件。

我想对此进行单元测试，但我不知道该怎么做，

我认为这是非常微妙的，imo 单元测试查询提供了负值。价值来自于使用存储库接口，允许您的单元测试显式配置您将从 influx 收到的响应，以便充分运用您的应用程序代码。这不会提供有关流入的反馈，这就是为什么集成测试对于验证您的应用程序是否可以针对流入进行有效配置、连接和查询至关重要。当您部署应用程序时，这种验证会隐式发生，此时就反馈而言，它比在本地和 ci 中通过集成测试进行验证要昂贵得多。

我创建了一个图表来尝试说明这些差异：

使用存储库的单元测试专注于您的应用程序代码，并且对与流入有关的任何内容提供很少的反馈/价值。集成测试对于验证您的客户端很有用（可能会扩展到您的应用程序，具体取决于测试的执行位置，但我更喜欢将其绑定到客户端，因为您已经获得了来自接口和调用的静态反馈）。最后，正如 @markus 指出的，从集成测试到 e2e 测试的步骤非常小，并且允许您进行 test your full service。

终于介绍完啦！小伙伴们，这篇关于《最简单的单元测试方法针对 influxdb 查询是什么？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！