testing error: import cycle not allowed in test

[JM]

Any idea why I get this error if i have my test in the same package name as the Entity class? If i add _test to the end of the entity package on my test file, it works.


C:\GoPath\src\github.com\xyz\api\domain\entity>go test
# github.com/xyz/api/domain/entity
import cycle not allowed in test
package github.com/xyz/api/domain/entity (test)
        imports github.com/xyz/api/domain/entity

FAIL    github.com/xyz/api/domain/entity [setup failed]

[Ian Lance Taylor]

If you put your test in package entity, then it really is in package
entity. It should not import entity itself--that is a package
importing itself, which is a (simple) cycle.

If you put your test in package entity_test, then it is in a different
package, and can import what it likes.

Ian

[Tong Sun]

On Tuesday, December 15, 2015 at 5:42:41 PM UTC-5, Ian Lance Taylor wrote:

On Tue, Dec 15, 2015 at 2:38 PM, JM <je...@magentatech.com> wrote:
> Any idea why I get this error if i have my test in the same package name as
> the Entity class? If i add _test to the end of the entity package on my test
> file, it works.
>
>
> C:\GoPath\src\github.com\xyz\api\domain\entity>go test
> # github.com/xyz/api/domain/entity
> import cycle not allowed in test
> package github.com/xyz/api/domain/entity (test)
>         imports github.com/xyz/api/domain/entity
>
> FAIL    github.com/xyz/api/domain/entity [setup failed]

I have exactly the same problem  -- `go test -v` and `go test -v ./...` will work yet `go test -v github.com/suntong/easygen` will fail, having the "import cycle not allowed in test" problem (ref https://codeship.com/projects/135255/builds/12400570), thus I have the same question.

If you put your test in package entity, then it really is in package
entity.  It should not import entity itself--that is a package
importing itself, which is a (simple) cycle.

If you put your test in package entity_test, then it is in a different
package, and can import what it likes.

So, the question comes down to, can we place our test in the same package? According to above explanation, put the tests within the same package will always got into the import cycle problem, and the solution is to move it to another package. This is really impractical, especially for small packages. Comments? Thanks. 

[JM]

it should work fine, just remember that from the test file, do not put the package name in from of the struct or members that you are testing, otherwise you will have these types of problems.  When in the same package you do not need to reference the package name if they are all in the same package.

[Tong Sun]

Oh, one thing I didn't make it clear is that I was planning to convert my test cases into (testable) examples. Thus those test cases will serve two purposes, testing my code while documenting how the lib can/should be used at the same time. 

Removing the package name from in front of the struct or members/member-functions(e.g., https://github.com/suntong/easygen/pull/2/files#diff-0, thank you bruston BTW) would be the last resort I want to take because of the above goal, as users seeing the example have to put them back before they can use them. 

So, I guess that I can't have both right? I.e., I can't leave my test in the same package if I want to achieve above right? Guess I have to split my test into a separated package then. That's the only option I have now, right? 

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/3hPEtCNm3XA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tong Sun]

On Wed, Feb 24, 2016 at 5:54 PM, Tong Sun <sunto...@gmail.com> wrote:

Oh, one thing I didn't make it clear is that I was planning to convert my test cases into (testable) examples. Thus those test cases will serve two purposes, testing my code while documenting how the lib can/should be used at the same time. 

Removing the package name from in front of the struct or members/member-functions(e.g., https://github.com/suntong/easygen/pull/2/files#diff-0, thank you bruston BTW) would be the last resort I want to take because of the above goal, as users seeing the example have to put them back before they can use them. 

So, I guess that I can't have both right? I.e., I can't leave my test in the same package if I want to achieve above right? Guess I have to split my test into a separated package then. That's the only option I have now, right? 

I guess the next question is, why the same test command `go test -v ./...`, works for my locally, but not works on codeship.com? It the exactly same command. I don't understand. If I can fix codeship build, then I don't need to the split I guess. 

[Dave Cheney]

I guess the next question is, why the same test command `go test -v ./...`, works for my locally, but not works on codeship.com? It the exactly same command. I don't understand. If I can fix codeship build, then I don't need to the split I guess. 

Can you please provide some details about what you tried to set on codeship, what you expected to happen, and what happened instead.

[Tong Sun]

On Wed, Feb 24, 2016 at 6:02 PM, Dave Cheney <da...@cheney.net> wrote:

I guess the next question is, why the same test command `go test -v ./...`, works for my locally, but not works on codeship.com? It the exactly same command. I don't understand. If I can fix codeship build, then I don't need to the split I guess. 

Can you please provide some details about what you tried to set on codeship, what you expected to happen, and what happened instead.

 

Simple, I accept everything default (because CI is very new to me), which is 

- `go get -t -v ./...` for prepare, and 

- `go test -v ./...` for testing

Here is how the test run in my local git:

.../git/src/github.com/suntong/easygen$ go test -v ./...

=== RUN   TestList0

--- PASS: TestList0 (0.00s)

        easygen_test.go:17: First and plainest list test

=== RUN   TestList1Text

--- PASS: TestList1Text (0.00s)

        easygen_test.go:28: Second test, with text template

=== RUN   TestList1HTML

--- PASS: TestList1HTML (0.00s)

        easygen_test.go:36: Second test, with html template

...

=== RUN   ExampleCommandLineOptInitFull

--- PASS: ExampleCommandLineOptInitFull (0.00s)

=== RUN   ExampleTestStringsCmp

--- PASS: ExampleTestStringsCmp (0.00s)

=== RUN   ExampleTestStringSplit0

--- PASS: ExampleTestStringSplit0 (0.00s)

=== RUN   ExampleTestStringSplit1

--- PASS: ExampleTestStringSplit1 (0.00s)

PASS

ok      _/export/git/src/github.com/suntong/easygen     0.039s

?       _/export/git/src/github.com/suntong/easygen/cmd/easygen [no test files]

here is what happened on codeship.com when that exactly code has been pushed to github:

# github.com/suntong/easygen

../src/github.com/suntong/easygen/easygen_test.go:7: import "github.com/suntong/easygen" while compiling that package (import cycle)

FAIL github.com/suntong/easygen [build failed]

?   github.com/suntong/easygen/cmd/easygen [no test files]

Full details at

https://codeship.com/projects/135255/builds/12400570

Thanks

[Dave Cheney]

In your first example, your code is not under GOPATH.

[Tong Sun]

On Wed, Feb 24, 2016 at 9:15 PM, Dave Cheney <da...@cheney.net> wrote:

In your first example, your code is not under GOPATH.

If by "first example" you meant my local git, then I'm afraid you are quite wrong my friend:

$ ls -l $GOPATH/src/github.com/suntong/easygen/

total 41

-rw-rw---- 1 tong tong 1075 2015-12-23 16:49 LICENSE

-rw-rw---- 1 tong tong 5796 2016-02-24 08:37 README.md

drwxrwx--x 3 tong tong   72 2016-02-24 08:24 cmd

-rw-rw---- 1 tong tong 1613 2016-02-24 16:09 config.go

-rw-rw---- 1 tong tong 3617 2016-02-24 16:09 easygen.go

-rw-rw---- 1 tong tong 7832 2016-02-24 17:19 easygen_test.go

drwxrwx--x 2 tong tong  936 2016-02-24 16:09 test

-rw-rw---- 1 tong tong  278 2016-02-24 16:09 tf-minus1.go

-rw-rw---- 1 tong tong  637 2016-02-24 16:09 tf-strings.go

-rw-rw---- 1 tong tong 1168 2016-02-24 16:09 tf-varcaser.go

$ head -8 $GOPATH/src/github.com/suntong/easygen/easygen_test.go 

package easygen

import (

        "fmt"

        "testing"

        "github.com/suntong/easygen"

)

If you do want to help, please do not guess -- it will take you less a second to pull down the whole github.com/suntong/easygen repo.

PS. Full disclosure, the $GOPATH/src/github.com/suntong/easygen is actually a symlink to my local git repo. 

[Dave Cheney]

I can tell that source is not inside GOPATH because the output begins with an underscore.

[Tong Sun]

On Wed, Feb 24, 2016 at 9:29 PM, Dave Cheney <da...@cheney.net> wrote:

I can tell that source is not inside GOPATH because the output begins with an underscore.

Oh. thanks.

[Tong Sun]

On Wed, Feb 24, 2016 at 5:54 PM, Tong Sun <sunto...@gmail.com> wrote:

Oh, one thing I didn't make it clear is that I was planning to convert my test cases into (testable) examples. Thus those test cases will serve two purposes, testing my code while documenting how the lib can/should be used at the same time. 

Removing the package name from in front of the struct or members/member-functions(e.g., https://github.com/suntong/easygen/pull/2/files#diff-0, thank you bruston BTW) would be the last resort I want to take because of the above goal, as users seeing the example have to put them back before they can use them. 

So, I guess that I can't have both right? I.e., I can't leave my test in the same package if I want to achieve above right? Guess I have to split my test into a separated package then. That's the only option I have now, right? 

Just FTR, I've found the perfect solution, converted my test cases into (testable) examples, while users seeing the example do not need to put package name back before they can use them. 

Details at https://github.com/suntong/easygen/commit/2aae45afef75218e1e9309e05ecc74a218b13c8d

[Dave Cheney]

I'm glad you found a solution, but IMO, if you want to use the go tool to build and test your code you should give up fighting its prohibition on symlinks.