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

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.

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

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.

Comment 5:

Status changed to WorkingAsIntended.

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.

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

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).