Re: NUnit 2.5: What's In It Now

> > > > > I don't understand that.> > >> > > With a Theory Explorer, you can't predict what the parameters> > > might be, therefore, you would have to have Assume. If you just used> > > if(condition) return; then you wouldn't have sure knowledge> > > that the Theory Explorer had generated cases that reached the> > > code to be truly explored, that is, the code after the> > > Assume.That's... This could lead to bad theories. For> > > example, if I wrote this theory...> >> > In my view, that's not Theory Explorer, it's Theory. I believe> > that the base implementation of Theory should provide for mixing> > up available parameters. The notion of a spearate program to> > suggest additional parameters (Theory Explorer) is an important> > idea and one we may see implemented some day. But a supplier> > of parameters for Theory is not going to be deterministic,> > at least in my view, the way a TestCase is.> > I think it's important when RUNNING a Theory for the run to be> repeatable, thus deterministic (if my definition of deterministic is> the same as yours). When you go exploring the space a Theory covers,> then it's important to be non-deterministic (but report the case(s)> where the Theory fails so that new cases can be added to the Theory> data source.)> 
 
I thought that a theory should be deterministic, at least with the user supplied data. I didn't think it would be as "rigid" as the dynamic test data. That provides the data in "parameter sets" - i.e. sets of data that we know work together, one of which is the expected output.
i.e. MyTest(int a, int b, int expected)
 
whereas I've seen theory syntax expressed (can't remember where) - where you specify the set of data for each parameter INDEPENDENTLY, and then the tool exercises the theory with whatever permutations it sees fit.
 
Is this what you mean by not being deterministic? I'd expect it to exercise every possible permutation, but can see how with large sets of data that may be unfeasible.
 
This does show, however, that with even user-supplied data (if you use a scheme like this) you might want/need assumptions even for user supplied data and not just a theory explorer - as the assumptions may be valid for only certain combinations of user input.
>> My implementation throws AssumeException, which is not equivalent to> return. My implementation of the catch of AssumeException in the test> case makes it equivalent, but I'm kind of separating Assume.That from> the handling of the exception. If you're talking about how the> exception is handled, then point taken. But I believe throwing the> exception has the right implementation for Theory...> 
 
I disagree about an exception for assumptions necessarily being the right implementation. For a start, there's a performance hit, and secondly, it means that we're going to bomb out of the first assumption - there's no way of seeing whether the data would be invalid for the other assumptions that follow the first failing assumption (I'm not necessarily saying we want that, but exceptions make that impossible).
 
I agree that having an Assume.That() in the code is a nicer syntax, but you could implement this by having your TheoryMethod set a static flag, then call Invoke, have Assume.That() set the flag and then, if any exception is thrown, it's OK if the flag is set. Of course, having statics means that we can't run the theories in parallel on different threads, so we probably wouldn't want to go down that route, but I'm using the example to say that an exception isn't necessarily the best way to implement the Assume.That() syntax.
 
Cheers,
Gary
_________________________________________________________________
Win 100’s of Virgin Experience days with BigSnapSearch.com
http://www.bigsnapsearch.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
nunit-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-developer