Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: cgo from within gotest #4030

Closed
gopherbot opened this issue Sep 1, 2012 · 11 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

commented Sep 1, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2012

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

This comment has been minimized.

Copy link
Author

commented Sep 1, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2012

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

This comment has been minimized.

Copy link
Author

commented Sep 1, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 5:

Status changed to WorkingAsIntended.

@perillo

This comment has been minimized.

Copy link

commented Feb 21, 2015

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.

@mikioh mikioh changed the title cgo from within gotest testing: cgo from within gotest Feb 22, 2015

@minux

This comment has been minimized.

Copy link
Member

commented Feb 23, 2015

@perillo

This comment has been minimized.

Copy link

commented Feb 24, 2015

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

This comment has been minimized.

Copy link
Member

commented Feb 24, 2015

@perillo

This comment has been minimized.

Copy link

commented Feb 25, 2015

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

This comment has been minimized.

Copy link
Member

commented Feb 25, 2015

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.