对 influxdb 查询进行单元测试的最简单方法应该是什么

Question

我有一项服务只对 influxDB 进行查询（读/写）。我想对此进行单元测试，但我不知道该怎么做，我读过一堆关于模拟的tutos。很多处理像go-sqlmock这样的组件。但是由于我使用的是 influxDB，所以我无法使用它。我还发现了我尝试使用的其他组件，例如goMock或证明过于复杂。我认为要做的是创建一个存储库层，一个应该实现我运行/测试所需的所有方法的接口，并通过依赖注入传递具体类。我认为它可以工作，但这是最简单的方法吗？我想到处都有存储库，即使是小型服务，只是为了让它们可测试，似乎被过度设计了。如果需要，我可以给你代码，但我认为我的问题是理论多于实际。这是模拟用于单元测试的自定义数据库的最简单方法。

Answer 1

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

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

我发现这是非常两极分化的讨论。测试实现是一种具体的实现，它为可靠、可重复的测试铺平了道路，这些测试支持轻松隔离和执行代码的特定组件。

---

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

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

---

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

带有存储库的单元测试专注于您的应用程序代码，并且在与流入有关的任何事情上提供很少的反馈/价值。集成测试对于验证您的客户端很有用（可能会根据测试执行的位置扩展到您的应用程序，但我更喜欢将其绑定到客户端，因为您已经从接口和调用上获得了静态反馈）。最后，正如@Markus 指出的那样，从集成测试到 e2e 测试的步骤非常小，并且允许您测试您的全部服务。

Answer 2

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

单元测试

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

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)，它提供我想要集成的东西，然后运行测试。