Re: nunit-developer Digest, Vol 22, Issue 11

On Wed, Mar 12, 2008 at 1:28 PM, Charlie Poole
<[email protected]> wrote:
>
>
> Hi Gary
>
>
> > > To support this approach, we need to either
> > > 1) allow test cases to be added at test execution time, or
> > > 2) allow a test to return more than one result
> > > I happen to lean toward the #2, but that's a detail - you
> > > can se that the two situations require different support
> > > from NUnit.
>
> I quite like the second case - I originally started looking at the
> extensibility because I was reading an XML file to find test data and the
> expected result, but I wanted visibility of the results. It would have been
> great if I could have called (poor pseudocode coming up):
>
> foreach(XmlElement element in file)
> {
> // read and process conditions;
> AssertWithoutFailing.That.Equals(somecondition, someresultname);
> }

I think you could do this now with an approach like this... again,
poor pseudocode back at ya... :-)

foreach(XmlElement element in file)
{
  try
  {
      Assert.That.Equals(somecondition, someresultname);
  }
  catch(NUnitException ex)
  {
     writeline(ex.message);
  }
}

> and have a sub-tree entry in the gui showing all of the AssertWithoutFailing
> calls - the someresultname would be a description of that case to show in
> the tree. This would be much simpler for a user to grasp for programmatic
> cases. The fact that the tests keep running even if AssertWithoutFailing's
> condition is false is important.

This was one of my first thoughts before implementing IterativeTest...
But I thought the tests would be clearer to read if the iteration were
outside of the test itself... so for me, it was an issue of the tests
being more readable.

> Thanks for the example.

Yeah, it is a great example... are we collecting these use cases somewhere?

> The parameterized tests do seem more suited to stuff like Theories, and to
> work with other tools that autogenerate the test case data.

And yet, it would make the tests easier to read, wouldn't it?

> My feeling is that it should only appear at load time (as a separate test)
> if the data is hard coded in an
> attribute as in RowTest.

That makes sense to me too.

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