Skip to content

ioquatix/turbo_test

Repository files navigation

TurboTest

Development Status

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 of parallel_testrake 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.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Sponsor this project

 

Packages

No packages published

Languages