Once Upon a 31st December …
A few days later, @headius started a discussion on ruby-core about the “Future of test suites for Ruby”. Participants quickly agreed that both RubySpec and the MRI test suite are valuable, have their own strengths and are complementary. After a couple exchanges with contributors from different Ruby implementations, I announced my intention to revive RubySpec as a collaborative effort.
Bringing RubySpec up to Date
MRI has been running RubySpec since its 1.9.2 release. But at some point RubySpec was forked because of some disagreements. That fork has been maintained by MRI committers to pass on all supported MRI versions but was never merged upstream.
The first step was therefore to merge rubyspec/rubyspec with the MRI fork.
@anthonycrumley started to fix many specs which were incompatible with MRI. @nurse and @hsbt proposed to have the new repository at ruby/spec. And finally @eregon made the actual merge (of 1426 commits!) and fixed the specs to run on all supported versions of MRI (2.0.0 – trunk).
The result is we now have a version of RubySpec with all major forks integrated, fully compatible with the reference implementation and run by many others.
Collaborating with Other Implementations
The goal of RubySpec is to define an accurate and runnable specification of the Ruby language. This is a challenging task and really makes sense only if many implementations use it.
JRuby has been using RubySpec for many years but needed a more efficient way to contribute back than a separate repository. The technical issues were solved and commits are now synchronized regularly in both directions. TruffleRuby, a new high-performance implementation of Ruby, is also extensively using RubySpec.
We asked Rubinius if they wanted to contribute to a common set of Ruby specs and they replied they were no more interested in that, although some sharing might be possible while they use RubySpec-like specs (it’s open source after all!).
Any contribution to RubySpec is a contribution to better specify Ruby and to guarantee consistent behavior across various implementations.
There is only one rule to contribute: respecting the existing style of specs. We want to maintain a good standard for specs and for that we just ask to use pull requests for new contributions.
The question is then, how to contribute?
There are many ways, but the most common are:
- Improve existing specs: clarify behavior, make them less implementation-dependent, etc
- Write specs for currently unspecified methods (there is a tool for it!)
- Write specs for new Ruby features
If you are not sure what to work on, just open an issue and ask!