There’s an additional issue that I only realized recently. You have to add t.Parallel() twice if you use the (common) idiom of table-driven tests and sub-tests. E.g.
func TestReverseRight(t *testing.T) {
t.Parallel()
for msg, tc := range testCases {
tc := tc
t.Run(msg, func(t *testing.T) {
t.Parallel()
// Actual test code…
})
}
}
Yeah this was something that surprised me coming to Go (and that I blogged about too) because I was surprised there wasn’t even a way to ask go test to force it to be parallel, you had to set it up yourself 😬
There’s an additional issue that I only realized recently. You have to add
t.Parallel()twice if you use the (common) idiom of table-driven tests and sub-tests. E.g.Oh, so Go tests are not parallel by default? That’s surprising, parallel is a much better default for the ecosystem!
Yeah this was something that surprised me coming to Go (and that I blogged about too) because I was surprised there wasn’t even a way to ask
go testto force it to be parallel, you had to set it up yourself 😬[Comment removed by author]
[Comment removed by author]