我有一个仅对influxDB进行查询(读/写)的服务。
我想对此进行单元测试，但是我不确定该怎么做，我读过很多关于模拟的tuto。很多处理类似于go-sqlmock的组件。但是当我使用influxDB时，我无法使用它。
我还发现我尝试使用的其他组件(例如goMock或testify)过于复杂。
我想做的是创建一个存储库层，该接口(interface)应实现我运行/测试所需的所有方法，并通过依赖注入(inject)传递具体的类。
我认为它可以工作，但这是最简单的方法吗？
我想到处都有存储库，即使对于小型服务，只是为了使其可测试，似乎都经过了过度设计。
如果需要，我可以给您代码，但是我认为我的问题是理论性的，而不是实用的。这是模拟用于单元测试的定制数据库的最简单方法。
最佳答案
按照其定义，如果您使用外部资源测试集成，那么我们所说的是集成测试，而不是单元测试。因此，我们有两个问题要解决。
单元测试
通常，您要做的就是拥有一个接受接口(interface)的数据访问层，而接口(interface)又易于模拟，并且您可以对应用程序逻辑进行单元测试。
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来覆盖所有测试用例，因为我无法使用模拟库，但是您可以看到图片。
至于过度工程:简单明了，不是，那不是过度工程。这就是我个人所说的适当的工艺。从长远来看，它将习惯它。也许不是在这个项目中，而是在 future 。
整合测试
狡猾我倾向于做的是在提交查询之前确保查询正确无误；)
例如，在极少数情况下，我确实想在CI中验证我的查询，我通常会创建一个Makefile，该文件反过来启动一个docker(-compose)，后者提供了要集成的内容，然后运行测试。