Thoughts on IronRuby and .Net Testing

December 01, 2008

Today I wrote some IronRuby tests targeting C# code (using both MSpec and the bundled Test::Unit). Things went out absolutely well.

While I won’t share the code in question yet, here’s a working example provided by John Lam on his blog a while back. This morning I decided I would start running it myself, to see how it goes.

$LOAD_PATH << File.dirname(__FILE__) + "/gems/mspec/lib" 
require 'mspec'

require 'mscorlib'
include System::Collections

describe ".Net Stack" do
  it "creates an instance with zero elements" do
    Stack.new.count.should == 0
  end

  it "contains one element after push" do
    s = Stack.new
    s.push "bob" 
    s.count.should == 1
  end

  it "let us peek the element pushed" do
    s = Stack.new
    s.push "bob" 
    s.peek.should == "bb" 
    s.count.should == 1
  end
end

Notice how it mixes IronRuby code with the .Net Stack CLR class.

Update (2025): I originally predicted that IronRuby and IronPython would deeply change the way people work with .Net. That didn’t pan out — IronRuby was eventually abandoned. But the experiment was valuable, and the cross-platform mindset stayed with me.

One thing that did hold up: Ruby’s dynamic nature makes it easy to generate test cases programmatically, replacing things like MbUnit’s combinatorial tests with plain code:

$LOAD_PATH << File.dirname(__FILE__) + "/gems/mspec/lib" 
require 'mspec'

describe "SupaComputa" do
  (1..400).each do |value|
    it "computes 2^#{value} without blowing" do
      SupaComputa.new.pow(2, value)
    end
  end
end

This doesn’t replace dedicated testing frameworks, but it shows how a dynamic language can simplify certain patterns that require special features in statically-typed ecosystems.

For more context, see John Lam’s talk on IronRuby at RubyConf 2008.