Closed JiangHanChao closed 1 year ago
一般的,根据单测mock打桩有效规则,我们强调声明了桩却未使用很可能导致测试程序正常执行却不符合期望,示例:
module_a.go
package moduleA func FuncA() error { return nil } func FuncB() error { return nil } func FuncC() error { if err := FuncA(); err != nil { return err } if err := FuncB(); err != nil { return err } return nil }
module_a_test.go
package moduleA import ( "errors" "testing" . "github.com/agiledragon/gomonkey" . "github.com/smartystreets/goconvey/convey" ) func TestFuncC(t *testing.T) { err := errors.New("test") Convey("test", t, func() { patches := ApplyFunc(FuncA, func() error { //return nil return err // due to mistakes this return nil modify to err }) patches.ApplyFunc(FuncB, func() error { return err }) defer patches.Reset() e := FuncC() So(e, ShouldEqual, err) }) }
上面这种情况下,单测仍然能执行成功,但并不是我们期望的逻辑(FuncB报错),并且此时我们能知道FuncB的mock是未使用的,故运行后理应报错,而不是通过,当前上面代码是能正常跑通过的,故而期望能添加检查mock桩的流程在执行单测完毕后,以防止此类逻辑漏洞
请参考我写的一篇文章:https://www.jianshu.com/p/4f37a584c7e1
一般的,根据单测mock打桩有效规则,我们强调声明了桩却未使用很可能导致测试程序正常执行却不符合期望,示例:
module_a.go
module_a_test.go
上面这种情况下,单测仍然能执行成功,但并不是我们期望的逻辑(FuncB报错),并且此时我们能知道FuncB的mock是未使用的,故运行后理应报错,而不是通过,当前上面代码是能正常跑通过的,故而期望能添加检查mock桩的流程在执行单测完毕后,以防止此类逻辑漏洞