moh*_*666 4 unit-testing mocking go
我正在尝试对调用该结构中的其他接收器函数的接收器函数进行单元测试。
假设我想测试 Three() 并在下面模拟对 two() 的调用:
type MyStruct struct {
a string
b string
}
func (m *MyStruct) one() int {
return 2
}
func (m *MyStruct) two() int {
return m.one() * 2
}
func (m *MyStruct) Three() int {
return m.two() * 2
}
Run Code Online (Sandbox Code Playgroud)
我正在遵循以下答案中的方法二。
我为每个想要单元测试的函数创建了一个自定义构造函数,并使用模拟版本覆盖这些方法。但我认为一旦函数数量增加,维护代码可能并不容易。
是否有任何首选方式来模拟此类功能?我希望官方文档有一些关于如何在不同场景中模拟事物的指南,类似于 Python 上的 mox 提供的内容。
另外,请注意,我不想使用第三方模拟库。
这是测试你的东西的一种非常不习惯的方式。在其他语言中可能需要所有这些模拟,但请不要在 Go 中进行。
在您提供的示例中测试代码的自然方法是: 1) 编写表驱动测试MyStruct.one
并确保测试所有案例。既然您知道one
工作得很好 2) 对MyStruct.two
. 请注意,在 Go 中测试未导出的内容是可能的、有用的和常见的。现在不再需要模拟某些方法,只需 3) 编写一些表驱动测试
MyStruct.Three
并检查它是否有效。
但是也许您的方法one
和two
做一些更有趣的事情,并访问环境(文件系统、数据库、网络)并且您不希望您的测试 Three
依赖于它?所以重构你的代码!也许Three
不应该是一个方法, MyStruct
而是一个将 aninterface OneAndTwoer
作为参数的函数,您的生产代码Three
使用“真实”MyStructs 调用,而您的测试代码使用不依赖于环境的 InMemoryMyStrcuts 调用它?你可以称之为模拟,我称之为接口的不同实现。
在您的示例中,给出建议很简单:对和使用表驱动测试one
,并且不要模拟。对于更现实的问题,建议可能会有所不同,但在不了解情况的情况下很难给出一般性建议。最好的一般建议是:查看标准库中的测试,您会在其中找到几乎适用于所有测试场景的有用模式。two
Three
归档时间: |
|
查看次数: |
2480 次 |
最近记录: |