Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Serial execution of package tests

Tags:

testing

go

People also ask

Do Jest tests run sequentially?

Jest will execute different test files potentially in parallel, potentially in a different order from run to run. Per file, it will run all describe blocks first and then run tests in sequence, in the order it encountered them while executing the describe blocks.

Does Go run unit tests in parallel?

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').


As others have pointed out, -parallel doesn't do the job (it only works within packages). However, you can use the flag -p=1 to run through the package tests in series. This is documented here:

http://golang.org/src/cmd/go/testflag.go

but (afaict) not on the command line, go help, etc. I'm not sure it is meant to stick around (although I'd argue that if it is removed, -parallel should be fixed.)


The go tool is provided to make running unit tests easier using the convention that *_test.go files contain unittests in them. Because it assumes they are unittests it also assumes they are hermetic. It sounds like your tests either aren't unittests or they are but violate the assumptions that a unittest should fulfill.

In the case that you mean for these tests to be unittests then you probably need a mock database for your unittests. A mock, preferrably in memory, of your database will ensure that the unittest is hermetic and can't be interfered with by other unittests.

In the case that you mean for these tests to be integration tests you are probably better off not using the go tool for these tests. What you probably want is to create a seperate test binary whose running you can control and write you integration test scripts in there.

The good news is that creating a mock in Go is insanely easy. Change your code to take an interface with the methods you care about for the databases and then write an in memory implementation of that interface for testing purposes and pass it into your application code that you want to test.


Just to clarify, @Jeremy's answer is still the accepted one:

Since my integration tests were only run on one package (api), I removed the separate test binary in the end and created a pattern to separate test types by:

  • Unit tests use the normal TestX name
  • Integration tests use Test_X

I created shell scripts (utest.sh/itest.sh) to run either of those.

  • For unit tests go test -run="^(Test|Benchmark)[^_](.*)"
  • For integration tests go test -run"^(Test|Benchmark)_(.*)"
  • Run both using the normal go test