testing: TestMain not working sequentially

[pjebs]

Package Structure:

/pkg
       x_test.go
/pkg/sub-package
       y_test.go

x_test.go

import "testing"
import "github.com/ory/dockertest"

func TestMain(m *testing.M) {
    pool, _ := dockertest.NewPool("")
    resource, _ := pool.Run("mysql", "5.7", []string{"MYSQL_ROOT_PASSWORD=secret"}) // Create and run container
    defer pool.Purge(resource) // Kill container
    
    m.Run()
}

func TestXXX(t *testing.T) {
// Do some tests using mysql container running
}

y_test.go

import "testing"
import "github.com/ory/dockertest"

func TestMain(m *testing.M) {
    pool, _ := dockertest.NewPool("")
    resource, _ := pool.Run("mysql", "5.7", []string{"MYSQL_ROOT_PASSWORD=secret"}) // Create and run container
    defer pool.Purge(resource) // Kill container
    
    m.Run()
}

func TestYYY(t *testing.T) {
// Do some tests using mysql container running
}

If I run the tests in each directory separately, it works perfectly:

1. It creates mysql container.
2. It Runs the tests.
3. It kills the docker container
4. Tests end and test results returned

If however I run go test -v ./... from the parent directory:

The tests error out at pool.Run saying that mysql container already exists.

I believe the correct behaviour should be that TestMain should be run independently and sequentially. Only After outer TestMain returns should the inner packages be tested.

That way the containers are already killed before the inner packages are tested, giving the opportunity for the inner package to create their own container (and cleanup themself)

[bcmills]

This is working as documented. Per https://pkg.go.dev/cmd/go#hdr-Testing_flags:

The 'go test' command may run tests for different packages
in parallel as well, according to the setting of the -p flag
(see 'go help build').

You can use the -p flag to control the number of processes that go test runs in parallel (see https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies), so -p 1 would run the tests sequentially.

That said, it is almost always preferable to structure the tests such that each invocation of the test binary works with its own (hermetic) resources.