TurboTest
Proposal
Discourse contains two tools (highly recommend you try them out for context)
bin/turbo_rspec
a parallel runner with non interleaving forking model. (leverages some ofparallel_test
…rake parallel:create
/migrate
to prep the dbs.bin/rake autospec
an automatic spec runner, which focuses on failed specs, like guard except that unlike guard it is interruptible.
Enter turbo_test
(name TBD, suggestions welcome).
turbo_test
will be a slot in replacement for the 2 tools Discourse use in a dedicated gem.
turbo_test
is to first be fully functional with rspec runners but longer term should also work with minitest
.
Features of the turbo_test
gem:
- MIT license, standard Rails code of conduct
- Pull based model for forked test runners. Master process manages a queue of tests, forked processes pull from the queue. Transport long term is agnostic though I would recommend initial implementation uses pipes.
- Pull model ensures that all the workers are running tests at all times. The parallel_test model of splitting up the tests upfront means that workers are often idle for long periods of time.
- Rake tasks for administration of partitioned test environments turbo_test:create / migrate / drop
- Non interleaved results (like
bin/turbo_rspec
) - While
turbo_rspec
is running, if you hit a specific key you can see right away information about the current tests that failed without halting the test process. - Documentation about how to handle custom sharding (memcached / redis) and so on.
- Minimal changes required to Rails projects that decide to use this.
- A key goal is deprecation of
bin/turbo_rspec
in Discourse. - Minimal dependencies (no explicit
rspec
,minitest
,redis
,pg
dependencies) - Stretch goal, once this is all done … extract
bin/rake autospec
into this gem as well. (I will do a mini specification if we get there) - Extra long term stretch goal, pull these concepts back into Rails proper.
Why not guard?
Guard at the moment does not support interruptible tests, this is a must have feature for turbo_test
.
Why not parallel_test?
It does not support a pull model so it would be close to a ground up re-write.