I’ve decided to try something a little different. Instead of getting a
word document passed around to look at and review, I’ve decided to put
my .NET interop test plan on our public Ironruby Wiki to get comments
from the team and the community. It’s not perfect, it’s what I’d
normally call 1st draft, but this is how I’m going to do this one.
You can find it here: http://ironruby.net/.NET_Testing_plans
We’re going to have to have a discussion about what .NET interop means
for IronRuby, and what cases are going to work, and what cases aren’t.
I’d love to have this page be a starting point for that discussion. Turn
the bullet points into links, and we can decide what the case means, how
it should look, and how it should work.
The way it works now is scenarios and cases. Each scenario describes a
.NET object or type. Each case is how to use that object or type. It’s
essentially a matrix in bullet form, scenarios are rows, cases are
columns, or vice versa. This leads to a lot of test cases, which is
another area I could use help. I would love if people would write tests
that correspond to these cases. I’ll be writing them too.
I’ll be writing them with the MSpec framework. I’ll be getting a folder
structure set up in the repo at $SVN_ROOT/trunk/tests/ironruby/interop.
The structure will be based on the sections of this page. I’ll try to
write up some pages and links on MSpec for people who aren’t familiar
with it.
As you read this, feel free to make changes, sign up for an account if
needed. If you have questions about what I meant, feel free to ask. I’ll
do my best to explain. This is as much an experiment for me as it may be
for you.
Thanks,
JD
http://blog.jredville.com
Hi Jim,
Interesting approach to writing a test plan - I think its a good idea.
My first question is how are you going to manage all of the test
inputs and expectations? I’m currently having this discussion at work
where we are lots of inputs (different sizes of scripts) and we need
to manage them in an effective manner, we throw a couple of ideas
around today. Still not 100% happy…
Are you going to have it folder based (Similar to how the current Ruby
Specs are wrote)?
/Deriving
/System.Delegate
/Test1
/Test2
/Test3
/Test4
/System.Enum
How are you planning to ensure you have all of the C# syntax covered?
Or are you just focusing on core use cases.
Similarly, how are you going to manage which test cases have been
created and which ones haven’t - based on your test plan?
I’m sure I will have more questions as I read the test plan 
Cheers
Ben
I’m actually sitting here looking at CMD thinking about the structure
right now. I’m leaning towards a folder based approach, similar to
RubySpec.
Right now I have the following folders:
- Loading .NET interop => interop/load
- Getting .NET Types => interop/mapping
- Using .NET Types => interop/using
- Deriving from .NET Types => interop/derivation
- Special .NET Concepts => interop/special
I’m not completely wild about these, but they are what I’ve thought of
so far. From there I’ll probably break it down by scenario.
I’m not focusing as much on C# syntax as much as .NET concepts. I’ll
probably do some analysis to figure out the equivalent classes, and any
boundaries to see if there are more cases to cut out or consider.
I’ll use the wiki to identify which tests are existing vs. which tests
are missing. Either a link from the cases, or another page with a table
on it.
I’m looking forward to the questions. I know I missed something, so I’m
interested in hearing what you, and everyone else have to offer.
JD