Re: NUnit 2.5: What's In It Now

Hi Kelly,

> >  My point was that Assume as a part of Theory does NOT 
> merely  return 
> > success. It's not the word that I find unexpressive,  it's that it 
> > doesn't seem to express what you are doing.
>
> I guess that makes sense. I'm just not sure I can think of 
> what it would do differently, other than how the framework 
> deals with it when the exception fires. There is no way to 
> return from the middle of a function other than an exception 
> (that I can think of) so I don't know how else you would 
> implement something like assume in the middle of the code.

I'm researching that - it's part of figuring out how to 
communicate results without exceptions. 

But that's not really my point...
 
> You could somehow do it before the method is called, but that 
> separates the assumption from the assertions, which I find 
> less expressive than having them close together in the code.

I'm just not willing to consider the throwing of the exception
separately from what is done with it by the framework. You've
been saying you want the assumptionexception to have meaning
in all tests. If that were to be so, I'd want that meaning
to be the same for all tests and I don't really know what
the meaning might be.
 
> The proximity of the Assumes to the Asserts seems fundamental 
> to me in terms of expressiveness. Does that make sense to you 
> in the context of Theory?

I like that aspect of David's implementation and it was my
first choice of how to go. But I won't jump from that to
the notion that no other way of doing it is possible, or
maybe even better. Gary has implemented a different approach,
for example. I want to write a non-trivial program using his
implementation. Then I want to write my own. Then I feel like
I'll be qualified to have a preference.

> >  > Of course, there is also the possibility that you might 
> grow  > to 
> > like Assume.That, if you used it as much as I used Assert.That...
> >
> >  I like it! I like it! I don't like it as a synonym for Succeed.
> 
> Sigh.

???
 
> >  I could be wrong, but I think you are having difficulty  accepting 
> > that NUnitTestMethod is itself an extension. If  so, consider what 
> > should happen if you use Assume.That in  a csunit test method.
> 
> Ok I get it now.

Cool.

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

You're right. Theory is probably going to be deterministic. Just
not under the direct control of the programmer as are normal
data-driven tests.
 
> >  That's not what your Assume.That does, however. We're not  
> (I'm not) 
> > talking about the general design of Theory here,  but about your 
> > particular implementation which equates  to the use of return.
> 
> 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...

Probably. But it's not the main point IMO. As a user, I
don't throw an exception. I just Assume something. You're
saying "As a user, I want to be able to make an assumption
and have it verified. If it succeeds, the test continues.
If it fails, the test terminates and succeeds." This 
doesn't make a lot of sense.

I think we have to design the entire interaction here,
not just focus on the implementation details.

> >  Assert.Succeed() has been requested and I'm inclined to  implement 
> > it, since it's trivial. Would you be equally  happy using 
> > Assert.Succeed in place of your non-Theory  uses of Assume.That?
> 
> As long as I could use a Constraint with Assert.Succeed... 
> but then it reads funny Assert.Succeed(Is.EqualTo(f)); ???
> 
> If you just do Assert.Succeed() that doesn't give you the 
> same level of expressiveness. If you did

As requested, it's just a command, like Assert.Fail or Assert.Ignore.
 
> Succeed.If(Is.EqualTo(f));

For that example, you could do
	if ( a == b ) Assert.Succeed();
but yes, I can see that a constraint syntax might be useful
for some cases.

> That would seem grammatically and syntactically similar to 
> what I'm proposing.

Yeah, but it actually says what it does.

> >  Even so, NOT all TestCase-derived clases handle the same Assert.
> >  For example, if you use an NUnit Assert in a csUnit test 
> class,  it 
> > comes up as an unexpected exception, not a failure. That's  because 
> > CsUnitTestMethod doesn't understand NUnit's exception.
> 
> Ok, I get it now :-)

Great.
 
 
> I agree that it is not currently possible. The question is 
> whether it is eventually desirable, and that's a separate question.

That's been decided. It will be possible in 3.0.


Charlie
 
> I assume a good design might have exception types orthogonal 
> to test types, but there may be cases I haven't considered, 
> so I'm not ready to assert my assumption. :-)
> 
> -Kelly
> 
> --------------------------------------------------------------
> -----------
> 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
> 



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