Multithread test runner
Alexander Demin
I wonder are any plans or ideas so far in the roadmap to implement
multithreaded test runner for GTest? Let's say if the "--gtest_jobs=8"
flag is set in the command line, GTest will use 8 parallel threads and
spread tests between them.
I've found it useful when for example if there is a test taking 1
second. Of course this kind of test is 100% wrong from the TDD
methodology point of view, but that parallel execution will allow to
manage it and make this test usable because if even one test takes 1
second all the rest of tests will have been done also in that second.
I've done already really dirty and quick hack for it using pthreads
(it should be quite portable even on Windows) though it is a bit
unstable yet. The first problem I've come across is managing the
output. Each test prints two lines (OK and DONE) which means I cannot
print anything until one test gets finished without messing up the the
output and preserving proper matching between "OK" and "DONE" lines.
At the moment the output in a multithread run is quite messy.
Secondly, I cannot preserve the flags properly when tests are running
in parallel and if they do change flags.
But technically all of those are managable at the first sight.
I agree this functionality could be argueable in general. Does anybody
else have a look at this direction? just interesting.
Thanks.
Alexander
Zhanyong Wan (λx.x x)
Running tests in different threads doesn't properly isolate them. The
tests share the same address space and can easily step on each other.
To do this right requires the test author to conciously design the
tests to be thread-safe, which can be tricky and means more work.
Therefore I'm reluctant to recommend this practice. Running them in
different processes gives you a better chance of success.
gtest already has some basic support for running tests in parallel
processes. It's called test sharding. We just need a test runner
script to take advantage of this capability. It shouldn't be too
hard.
--
Zhanyong