TestMain beyond the scope of a single package

[JohnGB]

Is there a way to have something like TestMain run once for a "go test" command, rather than be bound to the testing of a single package?

For example, let's say that I have 10 packages and before they can be tested, some time consuming code has to be run to set up the environment.  Right now I have to set up the environment for each package in a TestMain, which means running the setup code ten times instead of once.

[Tamás Gulácsi]

Put that setup code in a separate package, and run it through a sync.Once.

[Dave Cheney]

Not really, the go test package is best suited to unit tests. As you move away towards functional and integration tests, the worse a fit it will be for your requirements.

Why not write a small go program to set up and manage your func test environment, then call go test and finally clean up?

Dave

[Andrew Gerrand]

On 27 January 2016 at 17:38, Tamás Gulácsi <tgula...@gmail.com> wrote:

Put that setup code in a separate package, and run it through a sync.Once.

I don't think that will work as you expect.

When you run "go test pkg1 pkg2 pkg3" the Go command builds an executable for each package and executes each of them in parallel. Therefore each package's test binary has its own sync.Once value, defeating the purpose.

Andrew

[John Beckett]

I hadn't thought of that.  Do you have any examples of this being done, as I'm not clear on how I would get some go code to call the tests.

~ John

--
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/SxEkZhWl3QA/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.

[Dave Cheney]

On Thu, Jan 28, 2016 at 3:13 PM, John Beckett <jgbe...@gmail.com> wrote:
> I hadn't thought of that. Do you have any examples of this being done, as
> I'm not clear on how I would get some go code to call the tests.

I don't have any examples to hand. But you'd invoke the tests by
shelling out to `go test $PKG`

[John Beckett]

Assuming you mean something like:

cmd := exec.Command("go", "test", "integration_tests")

stdout, err := cmd.Output()

How would you structure it so that the tests would have access to variables within the go file which is calling the shell command?

If that's not what you meant, would you mind clarifying it for me?

~ John

[Gulácsi Tamás]

Ah, I see. Thanks for clearing it up!

[Dave Cheney]

The best approach would be to pass them as environment variables.

Depending on your needs you might prefer suite based testing wrappers like gocheck or goconvey.

[John Beckett]

Thanks for the advice, I'll give it a go.

On a related topic, it seems that integration tests are a key part of testing, and they should be able to be integrated well into the current testing framework if only there were some code like TestMain() which would call each individual package's TestMain().  How feasible or likely would it be to have something like this added in some future version of the go app?