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

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);
}
 
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.
 
Thanks for the example. The specific implementation (AssertWithoutFailing)
is possible in the longer term.
In the shorter term, NUnit only provides one mechanism for tests to
communicate info back to it: by 
throwing an exception. Of course, once an exception is thrown, the test
cannot continue.
 
In the longer term, we will provide a mechanism for tests to report failures
(or anything else) without
throwing an exception. Then things like reporting successful Asserts and
your example will be
possible. That will happen in the 3.0 timeframe.
 
For the coming 2.5 release, we're sticking with the mechanism we have. So
the notion of a test
that returns multiple results will need to be implemented by letting NUnit
do the iteration and
running the test multiple times. We would need something like.
 
public void MyTest( XmlElement element )
{
    // Your asserts here
}
 
or like this
 
public void MyTest()
{
    XmlElement element = SomeNUnitObject.Current as XmlELement;
    // Your asserts here
}
 
The test would, of course, be decorated in some special way. There are lots
of possibilities
so I won't list them all here - it would start an argument anyway., :-)
 
In fact, the whole idea of extensibility is that various people could
contribute various
syntaxes to make these tests work. NUnit would return a single test node but
once
the test was run that node would be expandable to show the results.
 
The parameterized tests do seem more suited to stuff like Theories, and to
work with other tools that autogenerate the test case data.
 
The other point in the thread is whether dynamic test data should appear at
load time or runtime - it would make more sense, to me, if parameterized
test cases were created at runtime (the user may change a file, change a
database etc. between test runs but not want to re-load their tests to pick
up the new dataset). When I say, test cases created at runtime, I mean from
a user's experience, what appear to be tests are populated in the GUI's tree
hierarchy, I dont' know how this effects on which NUnit objects are actually
created in memory.
  
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.
 
Charlie
 
Cheers,
Gary


  _____  

Messenger on the move. Text MSN to
<http://mobile.uk.msn.com/pc/messenger.aspx> 63463 now!

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