英文:
How to shared items in different testing files
问题
我想在许多不同的测试文件中共享项目,就像全局变量一样,但仅在测试范围内。
./1_test.go
./2_test.go
./3_test.go
// 在这些文件之间共享
var item *test.global
英文:
I want to shared items in many different testing files, just like global variable but only in testing scope.
./1_test.go
./2_test.go
./3_test.go
// shared between these files
var item *test.global
答案1
得分: 3
假设当前的包名是cpx,你可以在所有三个测试文件中使用包名cpx_test。Go语言允许在同一目录下有一个包(包含一个或多个文件)和一个测试包(包含一个或多个文件)。
使用这种方式,你可以在cpx_test作用域中声明全局变量,这些变量仅限于这三个测试文件。你应该将原始包作为外部包导入测试包中。
假设我们在cpx_1_test.go中有以下代码片段:
var (
complex1, complex2, complex3 *cpx.Complex
)
func TestAdd(t *testing.T) {
complex1 = &cpx.Complex{
Real: 1,
Imag: 10,
}
complex2 = &cpx.Complex{
Real: 2,
Imag: 9,
}
complex3 = cpx.ComplexAdd(complex1, complex2)
}
其他两个文件也可以使用这三个变量。但是有以下限制:
- 单独测试
cpx_2_test.go和cpx_3_test.go文件可能会导致错误,因为变量的初始化只在cpx_1_test.go中进行。 - 测试文件的执行顺序很重要。
go test cpx_1_test.go cpx_2_test.go cpx_3_test.go
- 测试用例的顺序也很重要。
TestAdd测试应该在其他任何测试函数之前进行测试。
另外,我使用了子测试来处理使用案例,这与你最初的想法不同,但如果单元测试相关联,这是有意义的。例如,可以使用一些相似的分类,比如TestOperators,其中包含子测试TestAdd、TestSubtract、TestMultiply、TestDivision。testing包提供了在*testing.T类型上定义子测试的Run方法。
func TestOperators(t *testing.T) {
var complex1, complex2, complex3 *cpx.Complex
complex1 = &cpx.Complex{
Real: 1,
Imag: 10,
}
complex2 = &cpx.Complex{
Real: 2,
Imag: 9,
}
t.Run("TestAdd", func(t *testing.T) {
complex3 = cpx.ComplexAdd(complex1, complex2)
assert.NotNil(t, complex3)
})
t.Run("TestSubtract", func(t *testing.T) {
complex3 = cpx.ComplexSubtract(complex1, complex2)
// 在这里进行测试
})
t.Run("TestMultiply", Multiply)
// 更多子测试...
}
func Multiply(t *testing.T) {
// 在这里进行测试
}
你可以使用内联匿名函数(如TestAdd和TestSubtract中)或一般的测试用例(如TestMultiply中)。如果使用函数,请确保函数名(标识符)不以"Test"开头,否则Go工具将将其视为单独的测试用例。输出结果将如下所示:
go test -v ./...
? gitlab.com/VagueCoder0to.n/Project [no test files]
=== RUN TestOperators
=== RUN TestOperators/TestAdd
=== RUN TestOperators/TestSubtract
=== RUN TestOperators/TestMultiply
--- PASS: TestOperators (0.00s)
--- PASS: TestOperators/TestAdd (0.00s)
--- PASS: TestOperators/TestSubtract (0.00s)
--- PASS: TestOperators/TestMultiply (0.00s)
PASS
ok gitlab.com/VagueCoder0to.n/Project/cpx 0.004s
英文:
Let's say the current package name is cpx, you can use the package name cpx_test for all 3 test files. Go allows 1 package (with one or more files) and 1 test package (with one or more files) in the same directory.
cpx
├── cpx.go
├── cpx_1_test.go
├── cpx_2_test.go
└── cpx_3_test.go
By using this, you can declare global variables in cpx_test scope that are only limited to the 3 test files. You should import original package in test as an external package.
import "gitlab.com/VagueCoder0to.n/Project/cpx"
Let's say we have the following snippet in cpx_1_test.go
var (
complex1, complex2, complex3 *cpx.Complex
)
func TestAdd(t *testing.T) {
complex1 = &cpx.Complex{
Real: 1,
Imag: 10,
}
complex2 = &cpx.Complex{
Real: 2,
Imag: 9,
}
complex3 = cpx.ComplexAdd(complex1, complex2)
}
The 3 variables can be used by other 2 files as well. But the limitations here are:
- Testing the
cpx_2_test.goandcpx_3_test.gofile separately may give you false errors as the initiation of variables is done incpx_1_test.goalone. - Order of test files in execution matters.
go test cpx_1_test.go cpx_2_test.go cpx_3_test.go
- Order of test cases also matters. The test
TestAddshould be tested before any other test function.
Alternatively, I use the sub-tests in use-cases, which goes against your initial idea, but it makes sense if the unit tests are related. i.e., have some similar classification, say TestOperators, with sub tests TestAdd, TestSubtract, TestMultiply, TestDivision. The testing package provides Run method on type *testing.T to define sub tests.
func TestOperators(t *testing.T) {
var complex1, complex2, complex3 *cpx.Complex
complex1 = &cpx.Complex{
Real: 1,
Imag: 10,
}
complex2 = &cpx.Complex{
Real: 2,
Imag: 9,
}
t.Run("TestAdd", func(t *testing.T) {
complex3 = cpx.ComplexAdd(complex1, complex2)
assert.NotNil(t, complex3)
})
t.Run("TestSubtract", func(t *testing.T) {
complex3 = cpx.ComplexSubtract(complex1, complex2)
// Tests here
})
t.Run("TestMultiply", Multiply)
// More sub tests...
}
func Multiply(t *testing.T) {
// Tests here
}
You may use inline anonymous functions (like in TestAdd and TestSubtract) or general test cases (as in TestMultiply). If using functions, make sure the function name (identifier) doesn't start with the work "Test". Else, go tools will consider that as a separate test case. Output will be:
go test -v ./...
? gitlab.com/VagueCoder0to.n/Project [no test files]
=== RUN TestOperators
=== RUN TestOperators/TestAdd
=== RUN TestOperators/TestSubtract
=== RUN TestOperators/TestMultiply
--- PASS: TestOperators (0.00s)
--- PASS: TestOperators/TestAdd (0.00s)
--- PASS: TestOperators/TestSubtract (0.00s)
--- PASS: TestOperators/TestMultiply (0.00s)
PASS
ok gitlab.com/VagueCoder0to.n/Project/cpx 0.004s
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。


评论