Follow

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Contact

TestMain for all tests?

I have a fairly large project with many integration tests sprinkled throughout different packages. I’m using build tags to separate unit, integration and e2e tests.

I need to do some setup before running my integration and e2e tests, so I put a TestMain function in a main_test.go file in the root directory. It’s pretty simple:

//go:build integration || e2e
// +build integration e2e

package test

import (
  ...
)

func TestMain(m *testing.M) {
  if err := setup(); err != nil {
    os.Exit(1)
  }

  exitCode := m.Run()

  if err := tearDown(); err != nil {
    os.Exit(1)
  }

  os.Exit(exitCode)

}

func setup() error {
  // setup stuff here...
  return nil
}

func tearDown() error {
  // tear down stuff here...
  return nil
}

However, when I run test:

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

$ go test -v --tags=integration ./...

testing: warning: no tests to run
PASS

# all of my subdirectory tests now run and fail...

I really don’t want to write a TestMain in each package that requires it and was hoping I could just get away with one in the root. Is there any solution that you could suggest? Thanks.

The only alternative I can think of is setting up everything outside of code and then running the integration tests. Maybe some shell script that does setup and then calls $ go test?

>Solution :

The go test ./... command compiles a test binary for each package in the background and runs them one by one. This is also the reason you get a cannot use -o flag with multiple packages error if you attempt to specify an output. This is the reason code in your main package doesn’t effect your sub packages.

So the only way to get this to work is to put all your setup logic in sort of "setup" package and call the shared code from all of your sub-packages(still a lot of work, I know).

Add a comment

Leave a Reply

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

Discover more from Dev solutions

Subscribe now to keep reading and get access to the full archive.

Continue reading