Re: Roadmap Updated

Hi Kelly, 

> >  Then I'm in favor of the first talks being about definitions.
> 
> Ok, that sounds fine. What would you like to begin defining?

The context of my comment was that you wanted to talk about
a Theory-based approach. I'm familiar with the literature, but
I don't know just what /you/ mean when you say that.
 
> >  Lambda expressions could provide users a way to create arbitrary  
> > code, which NUnit would then execute inside itself - but 
> why  would we 
> > want that?
> 
> Because they can be assigned to variables. I would guess you 
> could even do it in an attribute, like this:
> [Test code={dosomething()}]
> Although I haven't tried that...

What I meant was "Why would I want to allow users to run
arbitrary code inside a key NUnit component?" I have no
problem with allowing them to control the internals with
attributes or with running arbitrary code inside a test.
It's the combination of "internals" and "arbitrary" that
makes this sound like something I want about as much
as a poke in the eye.
 
> >  > I have a set of XML files containing data that need to be  > 
> > checked against a set of rules. I need to have multiple Tests  > or 
> > Theories run against these multiple files (so it's a two  > 
> > dimensional problem) to check them for internal consistency.
> >
> >  So, is the set of files a static list or is it somehow  
> figured out 
> > dynamically?
> 
> Let's just say it's all the files in a directory that match a 
> certain regular expression.
> 
> That's a pretty normal use case, I think.

And a superb example! Let's say I run the gui and let it stay
open for an hour. While it's sitting there, I modify the contents
of the directory in question.

Now I run the tests. Run time is now. Load time was an hour ago.

What implications does this have for your requirements?
 
> >  > I guess it's back to the stories then.
> >
> >  I may be misreading you, but I get the idea you want to 
> pick a best  
> > way to implement data-provision. For design, that makes sense. But  
> > for requirements, it doesn't. I think there is a requirement for  
> > static data providers and dynamic data providers.
> 
> I agree. I think the Theory concept combines the RowTest and 
> IteratorTest approaches nicely, and I've been in favor of 
> combining those two approaches for some time now.

I don't know what you mean by "Theory" but to my definition,
it's a lot more than a combination of two technical approaches.
It's a whole new concept and a way of thinking about things.

> I get the idea that you don't think Theory is comprehensive 
> enough somehow. Is that a proper read of your position? Or do 
> you just want to think about it more before committing to a 
> particular API?

The theory concept is a concept. It's not an API. I'd like
NUnit to implement some API that matches the underlying
concept of a Theory, as explored in the literature. I don't
want to dumb down the term to simply mean "some way of
writing data-driven tests" because it's more than that.

Aside from the definition, I haven't yet seen a proposed
API to which I might commit. Are you suggestiong one?

> Ok, then we're on the same page. Perhaps we could 
> differentiate between "general user" and "NUnit guru" for 
> purposes of conversation.

All right! There are some terms we can use! :-)

> I think that there should be lots of NUnit gurus out there, 
> and that they should have better extension points and 
> documentation to work from.

Agreed.
 
Charlie



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/