patterngoCritical
Proper package naming for testing with the Go language
Viewed 0 times
withnamingpackagetestingtheforproperlanguage
Problem
I have seen several different test package naming strategies within Go and wanted to know what pros and cons of each are and which one I should use.
Strategy 1:
File name:
Test file name:
See bzip2 for an example.
Strategy 2:
File name:
Test file name:
See wire for an example.
Strategy 3:
File name:
Test file name:
See strings for an example.
The Go standard library seems to use a mixture of strategy 1 and 2. Which of all three should I use? It's a pain appending
Strategy 1:
File name:
github.com/user/myfunc.gopackage myfuncTest file name:
github.com/user/myfunc_test.gopackage myfuncSee bzip2 for an example.
Strategy 2:
File name:
github.com/user/myfunc.gopackage myfuncTest file name:
github.com/user/myfunc_test.gopackage myfunc_test
import (
"github.com/user/myfunc"
)See wire for an example.
Strategy 3:
File name:
github.com/user/myfunc.gopackage myfuncTest file name:
github.com/user/myfunc_test.gopackage myfunc_test
import (
. "myfunc"
)See strings for an example.
The Go standard library seems to use a mixture of strategy 1 and 2. Which of all three should I use? It's a pain appending
package *_test to my testing packages as it means I can't test my package private methods but maybe there is a hidden advantage I am not aware of?Solution
The fundamental difference between the three strategies you've listed is whether or not the test code is in the same package as the code under test. The decision to use
There's nothing wrong with using both methods in a project. For instance, you could have
Test Code Package Comparison
Comparison of Strategies Listed in Question
package myfunc or package myfunc_test in the test file depends on whether you want to perform white-box or black-box testing.There's nothing wrong with using both methods in a project. For instance, you could have
myfunc_whitebox_test.go and myfunx_blackbox_test.go. Test Code Package Comparison
- Black-box Testing: Use
package myfunc_test, which will ensure you're only using the exported identifiers.
- White-box Testing: Use
package myfuncso that you have access to the non-exported identifiers. Good for unit tests that require access to non-exported variables, functions, and methods.
Comparison of Strategies Listed in Question
- Strategy 1: The file
myfunc_test.gousespackage myfunc— In this case the test code inmyfunc_test.gowill be in the same package as the code being tested inmyfunc.go, which ismyfuncin this example.
- Strategy 2: The file
myfunc_test.gousespackage myfunc_test— In this case the test code inmyfunc_test.go"will be compiled as a separate package, and then linked and run with the main test binary." [Source: Lines 58–59 in the test.go source code]
- Strategy 3: The file
myfunc_test.gousespackage myfunc_testbut importsmyfuncusing the dot notation — This is a variant of Strategy 2, but uses the dot notation to importmyfunc.
Context
Stack Overflow Q#19998250, score: 249
Revisions (0)
No revisions yet.