What's new? | Help | Directory | Sign in
Google
  
  
  
  
    
Search
for
Updated Apr 28, 2007 by brixen
Labels: Featured, Phase-Requirements, Phase-Design
ProjectPlan  
RubySpecs Project Plan

This project is about writing an executable Ruby specification using RSpec. It will be based on Rubinius' specs and infrastructure.

The JRuby team has offered to clean up their tests and contribute them to the general Ruby community by releasing them as a part of the RubyTests project.

The project can be split into the following parts:

Infrastructure (Florian Gross)

The infrastructure from Rubinius should provide a fairly good base. It already provides support for a critical thing: Testing an inferior (target) Ruby implementation that cannot yet run RSpec by using a superior (host) Ruby to control the specifications. Currently, this is implemented by wrapping the code to run on the target Ruby with the example {} method. (Later, it might make sense to add heuristics to automatically recognize the code for the target.)

The host/target system of Rubinius already has backends for Rubinius itself and MRI. I'd like to add support for JRuby, Ruby 1.9 and other implementations.

Charles O. Nutter of the JRuby project has expressed that having a mini RSpec implementation might be a good idea so that new implementations could be independent of other (more complete) Ruby implementations at an earlier stage.

Proprietary features of implementations could be included in sub folders. If done so, they should be disabled by default for all the other implementations.

We'll also need to deal with changes in 1.9. I think it is a good idea to keep additional specs for those in sub folders as well. When those features have become part of an official release we will merge them with the main files.

In general, everything that is changed because of a new Ruby version should be annotated with the version and what was changed in detail.

Core language specs (Florian Gross)

This is the specification of core language concepts and syntax. The target would only need to support puts() to be able to run the specs. Of course, it will need to implement more to actually pass them, but it shouldn't need to support Object#inspect or Marshal.dump to pass the test for conditional statements.

I'd like to base the order of the specs on the language introductions available at ruby-doc.org. Ideally, these would allow to develop a Ruby compiler / interpreter spec-first.

There is some parts of Ruby where there is quite a bit of controversity if they are an implementation detail or part of the defined API. This will need to be sorted out.

This might also include specificating YARV's byte code. This is not too important yet, but in the future I think there might be interest in directly executing byte code.

Core Runtime librabry

This is the specification are for thoses classes that support the OOP in Ruby. The most important ones should be specified first.

Core library specs (Pedro Del Gallego)

This is the specification of all classes, modules, objects and methods that Ruby provides by default. The most important ones should be specified first.

These specs can use the Object#inspect (and Marshal.dump?) functionality offered by the host/target infrastructure so they remain concise.

Standard library specs

Specifications for everything that ships with Ruby, but is not loaded by default.

For things that are already well specified elsewhere (for example YAML) it would be OK to only specify the Ruby API.

We'll try to concentrate on core infrastructure, the core language specs and the core library specs. Florian will primarily focus on language specs and Pedro on library specs, but that shouldn't be seen as a strict separation. We'll try to make these as complete and detailed as possible.

In general we will try to completely specificate one aspect before moving on to the next one. This is to avoid a shallow and fragmented specification. It's better to have a focused and detailed one.


Sign in to add a comment