Hi Pete,
I was kind of doing what you are saying but manually though. But after
seeing the specs, I stopped doing it altogether.
I wrote down the test and display the result on the console with puts.
Now run the script with ‘ruby’ on console and redirect the output to a
file (not MRI, I need to change based on what I hear) and then run the
same code against ir and do the same. After that I run my file compare
program and see the differences.
So it is possible to automate what you are suggesting, but don’t you
think the spec was already written to cover all the cases? Wouldn’t it
be a duplicate work? Just curious…
Thanks.
----- Original Message ----
From: Peter Bacon D. [email protected]
To: [email protected]
Sent: Wednesday, May 14, 2008 6:41:43 AM
Subject: Re: [Ironruby-core] changes to extname_spec.rb
I have been working on the basis that MRI is the reference
implementation
and so the specs should reflect that. If, on writing a spec, an obvious
bug
is exposed then we should be sending this on to the RubyLang lot and
getting
them to fix it.
Otherwise if it’s good enough for MRI its good enough for me.
By the way, I had this idea of creating a small program that would help
with
regression testing against MRI. Instead of writing full RSpecs, we
should
write snippets of Ruby that work the classes. The program would then
run
the snippets against MRI and IronRuby (and any other implementation if
you
wanted) and compare the results. That way you could directly check how
similar IR was to MRI without having to fix up the specs all the time.
Also
it would be much quicker and easier to write the specs since you
wouldn’t
have to check what the correct result should be in each case.
For instance, you could have the following snippets of code for the
Fixnum#div method:
2.div(2)
1.div(2)
5.div(2)
8192.div(10)
8192.div(-10)
(-8192).div(10)
(-8192).div(-10)
1.div(0.2)
1.div(0.16)
1.div(0.169)
-1.div(50.4)
1.div(0xffffffff)
0.div(0.0)
10.div(0.0)
-10.div(0.0)
13.div(0)
(obj = Object.new).should_receive(:to_int, :count => 0, :returning
=>
10)
13.div(obj)
5.div(“2”)
Obviously with some description mechanism and possibly some way of
specifying what should be considered in the output from Ruby: whether to
check the class and value of results returned; type and fields of
objects
passed in; if errors are raised the type and message of the error.
Anyone fancy knocking this up?
Pete