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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080815/d829d753/attachment.html>
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
On Fri, Aug 15, 2008 at 11:24 PM, Jim Deville <jdeville at microsoft.com>
wrote:> 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
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
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> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Ben Hall > Sent: Friday, August 15, 2008 3:56 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] IronRuby .NET Interop Test Plan > > 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 > > On Fri, Aug 15, 2008 at 11:24 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > 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 > > > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core