Automatically parallelize Convey execution?

[riannucci]

Would there be any interest in having Convey automatically launch a goroutine for each unique path through a test suite? Basically like t.Parallel(), but turned up to 11...

The reporting package would likely need to be changed to support this (hopefully without introducing a bunch of mutexes). Just wondering if it had been considered or if it was desirable.

[mdwhatcott]

hmm, this could be cool. Are you thinking that this would be the new default execution model and/or would there be a setting to toggle it? If it was a setting, it sort of feels like the failure mode setting--which isn't controlled by a command line flag, but rather via an argument you pass into the Convey function.

Imagining this was implemented, we might not even need to pursue a fix for issue #4 as the concurrent execution would drive out the same kinds of bugs that randomized execution would.

[mholt]

Would randomized execution with a seed like Ginkgo does it still be possible? I'd have to look into that further. Other than pseudo-randomized execution, what would be the benefit? Would tests actually run faster?

Cool idea -- I want to pursue this further.

[riannucci]

Yeah, that's what I was thinking (re: #4) and why I wrote this issue out. It would let go test -race do what it's good at.

I think you're right that it would show up in a fashion similar to FailureMode (e.g. as an argument to the Convey suite).

@mholt Yes, if GOMAXPROCS was >1 it should also lead to faster test execution times.

[riannucci]

Oh, I'm not sure if a seed would be possible, that's a good question. It would be relying on go's pseudorandom execution of goroutines to actually 'randomize' things.

[riannucci]

Looks like (http://onsi.github.io/ginkgo/#ginkgo-and-continuous-integration) their randomization is more along the lines of #4... It looks like the parallelzation that ginkgo -p does is similar to what you get with t.Parallel() in goconvey today