I'm writing a lot of go code, using the go test tool and the provided "testing" package for, well, testing. Most of the testing that I do is unit testing, within the TDD discipline. These "units" under test are never permitted to depend on stateful externalities like persistent storage, a network hop, etc., but receive fake, in-memory implementations of those externalities usually in "constructor/builder" functions (yes, I know they aren't constructors in the traditional sense).
It has long bothered me that the go test tool always runs test functions in the same deterministic order. This has, in a few cases, allowed race conditions to hide in the code. One way to find these bugs is by setting the -race flag. Another might be to always run unit tests in parallel...
Is there ever a situation in which isolated unit tests could not or should not always be run in parallel (using the -parallel flag)?
The parallel flag is actually a way to test the tests themselves (besides speeding them up). Finding a test breaks randomly when run in non deterministic order indicates a bad test as often as it does bad code.
Ruby's test runners do something interesting (both Rspec and Minitest) - they randomize the test order on each run, but print an integer seed that was used for the run. This allows the error to be reproduced while still making sure that no tests depend on implicit ordering. I don't know of any Go test runner doing this, but that would be quite useful.