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

> > > > My main conclusion so far is that there is an intrinsic> > > difference> > > > between extensions that provide data staticly and those> > > where it is> > > > only available at run time.> > >> > > I would assume the difference you are referring to is the> > > difference between the RowTest sort of approach and the> > > IterativeTest approach.> >> > Yes, at least in one aspect. In RowTest, we can look at> > the source code and tell how many test cases will be> > created. This would be true for any approach that places> > the data in attributes. To support this sort of approach,> > we need to be able to take a method and generate multiple> > test cases from it.> > Ok, that seems clear.> > > In your IterativeTest, we can only tell where the data> > will come from. It's not possible, in general, to figure> > out how many cases there will be by looking at the code.> > Correct.> > > Of course, some of your examples use a constant list> > of data points, but they would not have to be constant.> > A corner case, I get it.> > > 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.
 
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.
 
Cheers,
Gary
_________________________________________________________________
Telly addicts unite!
http://www.searchgamesbox.com/tvtown.shtml

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