Re: NUnit 2.5: What's In It Now

On Wed, Apr 9, 2008 at 6:58 PM, Charlie Poole
<[email protected]> wrote:
>  > 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.

I suppose you could call a function that somehow didn't return to the
caller... not sure how though.

>  But that's not really my point...
>
>  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.

I have given up on that request completely. I see your point now that
I understand the framework and context better. You are right. I don't
necessarily want Assume to work for Test anymore, or even
IterativeTest. I would like it for Theory still, and will work with
Gary to see that it gets into his extension.

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

Ok, that works for me.

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

You're hard to read sometimes. :-)  That's all.

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

Ok, then we're on the same page.

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

Why not? That's what Assume means in all the literature. The only
variant is that if the test terminates in ALL cases of testing the
Theory, then it is not a success.

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

Ok. I suppose the part you are interested in talking about is how to
go about specifying the data set going into the Theory. I agree that's
an important thing to talk about too. I've seen some of MbUnit's
approach to the problem. Some of it I like, some of it I think is
syntactically odd.

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

Ok...

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

It might also be nice to:

Assert.Fail(Constraint);

and so forth, but it does lead to the rather ungrammatic:

Assert.Fail(Is.EqualTo(4));

>  > That would seem grammatically and syntactically similar to
>  > what I'm proposing.
>
>  Yeah, but it actually says what it does.

Ok, ok.

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

Super.

-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