IronRuby projects newsletter

This “newsletter” is just part of the contents of for your reading
convenience, filtered down to projects with an updated status since last
time. A number of the projects have made good progress since a few weeks
ago. Please take a look at the projects that interest you, give feedback
to the project owners for bugs or features you care about, and discuss
ways of being involved if you are interested.


Mixing Ruby mocking with .NET mocking frameworks

Mark R., Ivan Porto C.

Investigated Moq and NMock and found that they were not a good match. A
project called Caricature has
been started to implement mocking directly in IronRuby


Daniele A.

Status: the master branch (compatible with Hpricot 0.6.164) and the
0.7_experimental branch (compatible with Hpricot 0.8.1) in the
repository both pass all the tests of the original Hpricot test suite,
what is left is a major clean up and some refinements to the code.


Daniele A.

Status: it somewhat works but needs to be tested, so bugs are expected
at this stage. A rewriting of the original definition file for Ragel is
planned to improve the C# code of the ParserEngine class which currently
is not so object oriented.

Project State: Alpha

Developer(s): Ray Vernagus

A Ruby wrapper on top of the .NET Data Provider
Model. This
wrapper will become the basis for an ActiveRecord adapter giving
IronRuby developers the ability to use the ActiveRecord gem with their
choice of database.


Jimmy S., Ray Vernagus

Details status about setting up Rails, running the unit tests, etc, is


Jirapong Nanta

Status: There are about 330 methods for OpenSSL library. Less than ten
RubySpec are
available. The focus of the project will be implementation the
functionality that is needed for RubyGems and Rails scenarios. e.g.
OpenSSL::X509::Certificate. Current results of running mspec ci
library\openssl can be found here
Work process:

  • Checkout ruby 1.8 source code

  • review OpenSsl implementation in C (ruby_1_8\ext\openssl)

  • review OpenSsl usage in RubyGems (e.g.

  • write RubySpec

  • implement a wrapper to System.Security.Cryptography namespaces

  • Refactor < - > Push

Some useful documentations can be found at

Porting SOAP Weather

Shay F.

Status - project was created, started porting the Silverlight code.


Shri B., Jirapong Nanta

We have reduced the number of failueres from 200+ down to about 20. The
current results are here The tests can
now be run from a
Dev.bat environment,
and will soon be part of continuous integration. So this project is
mostly wrapping up (successfully).


Chamini Gallage

Blocking IronRuby bug has been fixed. Need to try again with a newer
IronRuby version

Hi everyone,

Ivan and I have taken the interesting approach to collaboration by each
working on our own subtly different mock objects implementation,
communicating regularly and stealing each other’s ideas where necessary.
I released my crude attempt yesterday in case anyone wants to play
with it:

gem install markryall-orangutan (from


gem install orangutan (from rubyforge)

At this stage, you can only create stubs that implement a clr interface
well as pure ruby stubs) and then tell them how to behave (return
raise errors and yield values). I’ll add subclassing of clr classes and
nicer DSL for checking what actually happened.

See and

Before long, we’ll combine our efforts into one super mock object
that will mock objects like they’ve never been mocked before.


Yesterday I actually finished my implementation I think. I will
need to add some more matchers and expectations.I’m now documenting the
thing, creating the gemspecs and applying to rubyforge so that I can
the gem on rubyforge too.

From the start I wanted to do away with names like mock, stub, record,
replay, verify etc. Instead I took the advice from Roy Osherhove and
with a name of Isolator (Isolation might be better though) for creating

An Isolator will create what in Rhino.Mocks would be called a
PartialDynamicMock :slight_smile: In Moq it would be the Loose mocking strategy.

The naming of the methods for creating mocks is the one that JP Boodhoo
proposed WhenToldTo and WasToldTo.
To specify a stub/expectation on a mock you have one and only one way of
doing that with the method called when_told_to.
Then when you’re asserting you can use the was_told_to method

mock = Isolator.for(Ninja)
mock.when_told_to(:attack) do |exp|


Caricature handles interfaces, interface inheritance, CLR objects, CLR
object instances, Ruby classes and instances of Ruby classes.

I only embarked on this project because I really want to get IronRubyMVC
spec’ed with a ruby testing framework, on the other hand it has been

So now I’m trying to find out if people actually want more from a
library than setting expectations, verifying those expectations on
and/or number of times called.

I find that when I use mocking I tend to stay away of the fancy stuff
that it was this fancy stuff that confused the hell out of me in the
beginning because I needed to give it a place (which turned out to be
oblivion :slight_smile: ) Along with all the confusion that grew out of StrictMock,
DynamicMock, PartialMock and Stub.

So if anybody is up to reviewing the code please do. I welcome all
suggestions, issue submissions etc.

I couldn’t add support for events yet and commented out the spec that
that. I saw a tweet passing by from Curt where he was too tired to test
event support. Then downloaded the latest git but it still won’t work.
Do I
need to submit a bug for that or just be a little bit more patient ?

Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
GSM: +32.486.787.582
Author of IronRuby in Action (


  • “Vote for the man who promises least; he’ll be the least

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs