Idiomatic file & folder structure with integration tests

[JohnGB]

I currently have an API where the tests for each package include a mix of integration and unit tests.  It is my intention to separate out the integration tests (which in my case are simply calls to the APIs), from the unit tests and use build tags to select when I run the integration tests.

My current thinking is that I will have a folder for integration tests, and have a separate _test.go file for each API that I'm testing.

I'm looking for feedback on this, as well as some good examples examples and/or suggestions of a good file and folder structure to use specifically for integration tests?  

[Tamás Gulácsi]

For your "pkg" package, put unit tests in "pkg" package, but the integration tests into the "pkg_test" package (same folder).
This way your integration tests won't be able to use unexported things.

[JohnGB]

To prevent circular imports, I already use the structure of a "pkg_test" file for my "pkg" packages.  But I could use something like "pkg_int_test" for integration tests, although I don't see the benefit in doing that over simply having an "integration" folder with integration tests for each API.  e.g. user_test.go as part of the "integration" package.

Would you mind expanding on your suggestion, as I'm fairly sure there is something in your reasoning which I'm not understanding well.

[Tamás Gulácsi]

Nothing special. If your integration tests require instrumentation (complex setup), then it's quite reasonable to move it to a separate package.

[Manlio Perillo]

As far as I know there is no idiomatic directory structure, not only for testing but also for assets, general documentation , and so on.

The only one I'm aware is to put test data in the testdata directory. 

Regards  Manlio

[Markus Zimmermann]

We are using additional underscores for different kinds of _test.go files. For example _system_test.go and _component_test.go for system and component tests. These files have special build tags since they do not belong to the project's unit test. A simple `go test` will then only execute unit tests. Please note, that by default (afaik) linting and other analysis tools will only work on these files if you include the build tags. That is why I went through some projects to add that functionality (e.g. https://github.com/golang/lint/pull/153 is still pending). Some will say that a suffix like `_system_test.go` is too long, but with that you do not need to search for your tests in your project. They are, like normal _test.go files, right beside the code they are testing. Also, we are big fans of mocks/fakes and non-external fixtures e.g. we try to avoid saving test data in the /testdata folder. It is much faster to have fixtures included in the code or simply not at all, by generating them on the fly. In your case I can also say that mocks/fakes will benefit you a lot. In our case we try to have as few system tests as possible. Most tests with calls to an actual HTTP/database/... server or to the FS are mocked out. That means that most of our tests do not leave their test function and can be executed without external setups/fixtures (e.g. initializing a database, starting a HTTP server) and are therefore extremely fast.

It took a while for us to make this all happen but it is pretty neat to test all API servers and their interactions in a few seconds instead of hours.

[Leonel Quinteros]

I'm using a "tests" package where i have all the integration tests together with code needed by the tests (setup, mocking, etc.), all in files ended in _test.go even when there are no actual test functions in these files, so that doesn't gets compiled.