• Introduction
• Disable inlining
• Reset patch
• Async goroutine
• Conclusion

Introduction

In this blog post, we will discuss the common issues that arise while using gomonkey and how to resolve them.

Disable inlining

One of the most common problems while using gomonkey is not disabling inlining.

When run go test with gomonkey, we must disable inlining when compile by go test -gcflags=all=-l. It is also noted in gomonkey github. -l is the flag disable inlining and can be found in the go compile doc.

If you are running go test with Goland or other IDE, we could add this flag in IDE like below.

Furthurmore, why we must disable inlining. It is due to the implement of gomonkey like below.

So in detail, when patch a func A with gomonkey, gomonkey will get the instruction memory address of that func and modifiy the instructions there into instructions that call another func B we want to patch with. So it is crucital to call and execute func A, if compiler use a inlining, func A won’t be called, and the code lead to call func B won’t be executed either.

Reset patch

In each unit test, we must add defer patches.Reset() right after initializing patch.

As we mentioned before, when patches a func, gomonkey will modify the instruction of that func in memory. Reset() func will restore the modification.

If it is not restored, the patch in one test will influence other test, here is a example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

func MyTest() {
	fmt.Println("Origin")
}

func TestMyTest_1(t *testing.T) {
	MyTest()
	p := gomonkey.NewPatches()
	p.ApplyFunc(MyTest, func() {
		fmt.Println("TestMyTest_1")
	})
	MyTest()
}

func TestMyTest_2(t *testing.T) {
	MyTest()
	p := gomonkey.NewPatches()
	p.ApplyFunc(MyTest, func() {
		fmt.Println("TestMyTest_2")
	})
	MyTest()
}

The output of the demo is like below. We find that the patch in TestMyTest_1 influence TestMyTest_2.

1
2
3
4
5
6
7
8
9

=== RUN   TestMyTest_1
Origin
TestMyTest_1
--- PASS: TestMyTest_1 (0.00s)
=== RUN   TestMyTest_2
TestMyTest_1
TestMyTest_2
--- PASS: TestMyTest_2 (0.00s)
PASS

Async goroutine

When there is async goroutine in unit test, the patch may be reset before it is used in async goroutine, which may lead to failure of unit test. Here is a example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

var i int32 = 0

func a() {
	atomic.AddInt32(&i, 1)
}

func b() {
	return
}

func businessFunc() {
	// Some business logic
	time.Sleep(time.Millisecond)
	go a()
}

func TestBusinessFunc(t *testing.T) {
	for i := 0; i < 10; i++ {
		t.Run("test", func(t *testing.T) {
			patches := gomonkey.NewPatches()
			defer patches.Reset()
			patches.ApplyFunc(a, b)
			businessFunc()
		})
		time.Sleep(time.Second)
	}

	if i != 0 {
		t.Errorf("a should be 0, but got %v", i)
	}
}

The output is likw a should be 0, but got 5. In this example, businessFunc() call a() asyncly, and a() is patched into b() in unit test. But from the result, a() has been called 5 times rather than never.

The reason is that when execute patches.Reset() the async goroutine may not be executed, so after patches.Reset() the a() func restore its original logic, so the async goroutine will execute it.

In order to prevent it, we must not run patches.Reset() until all goroutine finish.

Conclusion

In conclusion, gomonkey is a powerful tool for testing, but we need to be careful while using it. We should disable inlining, reset the patch after each test, and handle async goroutines properly. By following these practices, we can write reliable and efficient unit tests.