testing: cgo from within gotest

[gopherbot]

by d.wright.dev:

Not being able to use cgo from within gotest prevents integration of regression testing
on packages that make use of C.

What steps will reproduce the problem?

1. import "C" from a new test file
2. run go test <package> on its package

What is the expected output?

> ok/FAIL <package> 0.020s
> ...

What do you see instead?

> can't load package: package <package>: use of cgo in test
/path/to/file/using/cgo/dlbug_fail_test.go not supported

Which compiler are you using (5g, 6g, 8g, gccgo)?

8g

Which operating system are you using?

OS X 10.8.1 (12B19)

Which version are you using?  (run 'go version')

go version go1.0.2

Please provide any additional information below.

[rsc]

Comment 1:

This is not strictly true.
You can test a package that imports "C" just fine.
What you cannot do is import "C" in the test files.
Why do you want to do that?
Russ

[gopherbot]

Comment 2 by d.wright.dev:

Fair enough, but the idea of a test case is that it's as small and local as possible to
reduce the number of variables. Importing an external package in its entirety sort of
defeats that notion.

[rsc]

Comment 3:

I'm a bit confused. It sounds like you think I said the answer is to
package up the C functionality you need during your test in some other
package and then import that "external" package.
What I'm saying is that import "C" is an implementation detail of the
package you are trying to test. The test itself shouldn't need to
import "C" at all.
Russ

[gopherbot]

Comment 4 by d.wright.dev:

> I'm a bit confused. It sounds like you think I said the answer is to
> package up the C functionality you need during your test in some other
> package and then import that "external" package.
No, I follow your reasoning completely. There's nothing wrong with saving some labor by
requiring some indirection, and it actually may better isolate the issue. It's just
counterintuitive.

[rsc]

Comment 5:

Status changed to WorkingAsIntended.

[perillo]

Wanting to use cgo in a test seems reasonable to me.
As an example I implemented the makedev, major and minor functions in Go, and the natural way to test the implementation is to use the C implementation as a reference.

[minux]

You can use cgo in non _test.go files. See how the cgo test itself is written. http://golang.org/misc/cgo/test/ Basically, in http://golang.org/misc/cgo/test/cgo_test.go, we directly each TestXXX(t *testing.T) to testXXX(t) defined in other files that can use cgo.

[perillo]

On Tue, Feb 24, 2015 at 12:31 AM, Minux Ma notifications@github.com wrote:

You can use cgo in non _test.go files.

See how the cgo test itself is written. http://golang.org/misc/cgo/test/

Basically, in http://golang.org/misc/cgo/test/cgo_test.go, we directly
each TestXXX(t *testing.T) to testXXX(t) defined in other files that
can use cgo.

Thanks.
However this is simply too much "complex" for my use case, since I will
need to create a separate test package just to test 5 lines of code.

Manlio Perillo

[minux]

If you actually read the code that I provided, you will see that you don't need to create another package.

[perillo]

On Tue, Feb 24, 2015 at 9:09 PM, Minux Ma notifications@github.com wrote:

If you actually read the code that I provided, you will see that you don't
need to create another package.

What I meant is that you need to put the test in a different package.
This is what it is done in test/cgo_test.go.

The alternative is to put cgo code inside the package being tested, but
this means that
the cgo code will be build (slowly, compared to gc) and will be included in
the generated binary package.

Ideally I would like to have the cgo code built and used only by the test
code.

Thanks

—

Reply to this email directly or view it on GitHub
#4030 (comment).

[minux]

Of course not. There are some packages under misc/cgo/test, but that is because of other constraints. See cgo_test.go and issueNNNN.go.