The Official RubySpec Website and Its Google Summer of Code Students

Posted by Mirko Stocker on May 26, 2008 11:22 AM

Community

Ruby

Topics

Unit Testing,

Agile Techniques

Tags

RubySpec,

Google Summer of Code,

Testing

Brian Ford announced the official website of the RubySpec project:

The project aims to write a complete executable specification for the Ruby programming language based on RSpec-style specs. The project started as a glimmer in the eye of an early Rubinius contributor and has since grown to over 6900 examples and 25600 expectations, with contributions from many dedicated folks.

The Ruby language does not have any formal standard that specifies its desired behavior and with the growing number of Ruby implementations, the need for a specification is evident. In the spirit of modern software development, an executable specification is preferable over other forms of written documentation, simply because its much easier to validate the conformance when the suite of specifications can be executed and feedback is given almost immediately.

Two students participating in the upcoming Google Summer of Code, Federico Builes and Arthur Schreiber, are going to improve and extend the Ruby specifications. We talked to both of them to learn on what they'll be working on during the summer.

Federico Builes is a Columbian student who got involved with Ruby about two years ago when he was looking for an alternative to C—he is now a contributor to the Rubinius project. We asked him about his goals for the Google Summer of Code:

The first part of the project is to write specs (tests) for some of the libraries in Standard and Core Lib, namely: REXML, YAML, Logger, Socket, and IO.

The other part of my project (which was a suggested by Charles Oliver Nutter) is to take a look at the different test cases that the other Ruby implementations use and port them to Rubyspec, trying to make the spec set as complete as possible.

We also asked Federico about his approach to find the code that lacks tests:

Since I already have a defined set of libraries that I'm working on, I just go straight into these libs documentation, see what a method should do and then spec that out. If it works as documented, great, if not I'll start reading the source to see what's happening.

One of the advantages to reading the documentation instead of going straight to the code is that you'll often see that some things don't work as expected. When I started the REXML spec coverage I got to send three or four patches the same day for some small bugs or documentation stuff that was not up to date and now they've been fixed in Ruby 1.9. With Rubyspec being part of MRI now I think this kind of things will be discovered and fixed much sooner.

Also, MSpec, the simple clone of RSpec we use in Rubyspec, allows you to generate stubs for libraries that don't have tests yet, and then you can tag them as incomplete, ready, failing for X or Y implementation, etc. This way you can see that some lib has been giving problems in some implementation of Ruby, and you can go ahead and fix it, knowing that you have the test suite covering your changes as you go along.

The second student working on Ruby specifications is 19 years old Arthur Schreiber from Germany. He's been involved with Rubinius since May 2007 and contributed smaller patches, bug fixes, and many specs. We asked him the same set of questions:

My goals for GSoC are to create or improve the specs for a handful of Ruby's Standard Libraries, including the CGI, StringIO, Net, Set and some other smaller libraries.

MSpec, an RSpec compatible BDD Framework developed by Brian Ford of the Rubinius Team, is one of the main tools we use. The idea behind it is to allow even the less complete implementations to run the specs by avoiding the more advanced features of the Ruby language.

MSpec supported a basic coverage utility, that could point out methods that had no specs yet at all, but it was removed due to the splitting off MSpec and the Rubyspecs into their seperate libraries. Brian Ford will look into re-adding that feature as soon as possible. There is also thinking going on about using RCov to check Spec coverage of the Standard Library specs.

If you want to contribute, Vladimir Sizikov wrote a RubySpec quick starting guide that explains the basic steps to get started. To learn more about the project, visit the RubySpec website.

• Older >