Re: Data Driven Addins

> NUnit itself has not paid a lot of attention to this issue> in the past: everything is a TestFixture and you have to > bend your problem to fit that construct. I'd like to start> thinking a bit more in terms of the problems to be solved,> and give the user solutions that match the problem.> > Examples of what I see as different problems are:> > 1) I want a shorthand way to specify the same test method> with several different arguments, so I don't have to> type it many times.> > 2) I want to run the same test in different contexts - with> a different database, under a different culture, etc.> > 3) I want to be able to supply an open-ended list of > parameters to a test and run all of them as if they > were separate tests.> > 4) I want to test multiple implementations of the same> interface using a standard set of tests.> > 5) I want to specify general statements about how a > method should work and provide data to test those general> statements.> > 6) I want to specify general statements about how a method> should work and have the framework generate data sets to> test those statements.> > Add your own...> > Many of the above can be solved by a data-driven implementation,> but I'm not convinced that it serves the user best to make> them all /look like/ the same thing.> > Reading what I've written, I think I'll copy this back to the> list so others can comment.> > Charlie> 
Hi Charlie,
 
That is a good post to get us thinking. For instance, rather than getting my tests to change the current culture, it may have been easier to just change Windows' regional settings and re-run the tests, but I wanted things ran in as automatic a way as possible - without mandating that the coder remembers 20 things to do on each code change (we are trying to automate testing...)
 
Out of interest, can you see another way to solve that specific problem? It might be my knowledge of unit testing tools that took me down that route - that case is solved by following FxCop rules on globalization, but I was looking for a different example of parameterized fixtures. Maybe actually grasping for straws with - it might be something that isn't commonly necessary in real life (and xUnit.net's gone away from having any fixtures).
 
I think that it could be confusing for the user in any case - most of these could have common syntax. i.e. 6) could be written as parameterized test, that the user generates data for manually, then they realize they can add a Pex attribute and have data generated automatically (and the theory papers do speak about having the test data generated manually) - there seems to be a lot of crossover between these pieces of functionality.
 
I think I am rambling a bit about this, and my thoughts aren't that clear, but I hadn't seen the problems to be solved expressed as clearly as you'd put them down (do you have any ideas of any of the solutions ;-) ).
 
Cheers,
Gary
 
 
_________________________________________________________________
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx

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