Re: Modificatons to NUnit 2.5 Data-Driven tests

On Sat, May 31, 2008 at 3:09 AM, Charlie Poole <[email protected]> wrote:
> Hi All,
>
> Kelly has pointed out several issues with DataSourceAttribute, all of
> which revolve around the fact that the property runs at load time,
> which is before the tests are ever executed. This leads to some
> potential user confusion, which is not helped by the fact that
> the attribute name /sounds like/ data that is input to a test, rather
> than a set of parameters used to construct the test.
>
> 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,
which leads me to wonder if there isn't a somewhat better way. Then I
think perhaps there isn't... :-)

> I also think now that limiting the data source (or factory) to be
> a static property is too limiting. We should allow properties, methods
> or fields and let them be either static or instance. Users will just
> need to be aware that the instance creating the test cases is not
> necessarily the same as the instance that executes them.

I think both instances should be the same. I can think of no reason
that they wouldn't be. 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.

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

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