Re: Modificatons to NUnit 2.5 Data-Driven tests

Hi Kelly, 

> > MbUnit has a long history of using "Factory" in the names of 
> > attributes that create tests. This may be a better naming 
> convention, 
> > even though they seem to have had one or two users confused 
> by the issue as well.
> > I'm inclined to using it for us as well.
> 
> I suppose that could help to some extent. The part that makes 
> me stop and think is that the only real solution is 
> more/better documentation, 

There is currently zero documentation, so it's evident we need
more and better. We agreed on this many cycles back, so I think
you're beating a dead horse.

> which leads me to wonder if there isn't a somewhat better way. 
> Then I think perhaps there isn't... :-)

If, as I believe, most use cases will involve constants, then I
think you overstate the problem of understandability.

> I think both instances should be the same. I can think of no 
> reason that they wouldn't be. 

We have discussed this one or two times and I just restated
the issue for Jeff, who wasn't part of the discussion. I thought
you had ended by agreeing with me that it isn't possible to do
what you are asking in THIS type of data source, as opposed to
what we were calling dynamic.

Here is the logic:
1. Tests may be loaded once but executed many times.
2. Each execution gets a new set of fixture objects, which
are created before the run and destroyed afterward.
3. Since we use a different instance for each run, it is
not possible to also use the same instance for the
one-time load.
4. If you want to use the same instance to read the data
(as opposed to load the tests) that is possible. That is
what we were (I was?) calling dynamic tests. Such tests
cannot appear in the initial load, but only in the result
tree.

> The reason you would want them 
> to be the same is if you set a member variable to a value in 
> the IEnumerator field, you would be confused by the fact that 
> it wasn't set when your test was entered. Now, that makes 
> sense to us who are really quite familiar with the structure, 
> but it doesn't make sense to a casual user.

What you are describing seems to me as either an anti-pattern
or (giving the benefit of the doubt) an advanced technique. :-)
In either case, the casual user would not need to understand.

Can you give a use case for this technique?

In any case, I think this is a job for the (I thought) agreed
upon /separate/ dynamic test feature. (Which, btw, I want to
work on next)

Charlie

> > That's the general way I'm looking at modifying this stuff. 
> Any thoughts?
> 
> I'd still really like to see the case simplified such that 
> when you have only one parameter to your test function, such 
> that the one parameter could be an object, rather than having 
> to be put into an object array. Stuffing one object into an 
> object array of length one in your enumerator makes the code 
> less readable and harder to write too IMHO. That's my only 
> really strong thought at this point. Seems that it would be 
> pretty easy to figure out from the metadata if the items in 
> the IEnumerator were of type object[] or of type object...
>
> The point where you could disagree is that it makes it 
> inconsistent when you have to go to two or more parameters, 
> but then it really IS an array... :-)

I believe I suggested - and you filed - a bug. In case it
wasn't clear, that means I was agreeing with you. :-)
 
> -Kelly
> 
> --------------------------------------------------------------
> -----------
> 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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 



-------------------------------------------------------------------------
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/