Re: Modificatons to NUnit 2.5 Data-Driven tests

On Sat, May 31, 2008 at 7:53 PM, Charlie Poole
<[email protected]> wrote:
> 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.

Sorry, didn't mean to do that.

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

Possibly. Many of my current data driven tests do not involve
constants, but rather file sets. So I may have a different mind set.
You've always said you would optimize for programming tests, and that
data tests would be considered second. So I think your thoughts on the
matter are consistent. I can send you my current set of data-driven
tests off line if you think it would be at all helpful to look at a
real example.

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

Sorry, I wasn't remembering about the two types. I'll reserve further
comment until after I see your implementation of the second type as
well.

> Here is the logic:
> 1. Tests may be loaded once but executed many times.

That makes a pretty big difference.

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

Ok, this all makes sense. Now that you say it, I even remember it.
Kinda tired lately...  :-)  Too many irons in too many fires at once.

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

If it is an anti-pattern, then perhaps in the documentation we should
promote that the IEnumerator field should be stateless. At least I
think that's what you're getting at.

> Can you give a use case for this technique?

At the moment, I can't... but I'll keep thinking about it. I had one
the other day. I think I'm just exhausted today. Sorry. Can't seem to
make my brain function properly at the moment.

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

This thread is getting too chopped up in my head... That's my problem
not yours of course... :-)

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