Bug #18731
closedParallel test-all sometimes does not run at all some tests
Description
In TruffleRuby I've noticed that some CRuby tests sometimes run or not, non-deterministically.
The TruffleRuby CI currently runs CRuby tests with -j4
.
Today I investigated and I think I've found the reason for it.
One occurrence of this bug is for:
- https://github.com/ruby/ruby/blob/master/test/ruby/test_method.rb
- https://github.com/ruby/ruby/blob/master/test/ruby/test_inlinecache.rb
Both define a test class TestMethod
.
The parallel runner distributes files across processes.
If the same worker process gets both files, then all tests in the second file are not run at all! (the file is still loaded).
The reason seems this line:
https://github.com/ruby/ruby/blob/8751c5c2672d1391c73d9dec590063d27bed7e4c/tool/lib/test/unit/parallel.rb#L128
(it's also possible to reproduce with just these 2 files, -j2
and not the full test suite, and having one worker start very slowly so the same worker gets both files)
Test::Unit::TestCase.test_suites
is an array of classes, and so here because TestMethod
was already defined by the first file loaded, the result of Test::Unit::TestCase.test_suites-suites
is empty, and nothing gets run.
This doesn't seem an issue when not running in parallel/using -j
.
But that's rare/impractical because test-all is very slow without -j
.
For this specific case it seems we should rename the class in test_inlinecache.rb
, but I suspect there are more name conflicts and the parallel runner should be fixed to handle this.
<rant>
FWIW, this test/unit code seems pretty messy, very long lines, duplication, hard to follow with the mix of minitest/test-unit, etc. I don't understand how this code is any better than mspec
. It seems far more complex and hacky.
And that's probably why Ruby implementations except CRuby run MRI tests only when they have no choice, it's so annoying to work with, so many unnecessary subprocesses (very slow to run, annoying to debug), many CRuby-specific tests, so many unreliable tests, many metaprogramming-defined tests which are very brittle, lots of global state and coupling, etc.
</rant>