Fwd: Assume

Dang old reply-to field anyway...

On Thu, Feb 14, 2008 at 4:09 PM, Charlie Poole
<[email protected]> wrote:
> Hi Kelly,
>
> > > >   I didn't see that you responded to the idea of creating
> > an Assume
> > > > class that was the same as the Assert class, except that
> > instead of
> > > > throwing the exception, it just returned silently if the result
> > > > returned true.
> > > >
> > > >  The example was:
> > > >
> > > > [Test]
> > > > public void Divide()
> > > > {
> > > >   Assume.That(denominator, Is.Not(0));
> > > >   Assert.That( ... numerator/denominator ...); }
> > > >
> > > >   Would that be easy or hard?
> > >
> > > Well, I don't know how to do it in normal managed code -
> > assuming you mean return from the Divide method.
> >
> > Sure you can. You just throw an AssumptionMetException which
> > would be caught by NUnit and ignored.
>
> That's not returning. I know how to throw an exception. I
> don't know how (outside of assembly language stack manipulation)
> to force a two-level return.
>
> It sounds like you didn't mean return as I took it. :-)

Ah, well, in general, throwing an exception "returns", but not with a
return statement... :-) The point is that there is a pretty
straightforward implementation that could make it look like it
returned.

> > > However, I don't think you want it to just return, which
> > would imply a
> > > successful test. Rather, you probably mean to have it return some
> > > indication that this particular data is not being used... right?
> >
> > Having it just return is good enough. All you are doing is
> > stating the preconditions that are required by the subsequent
> > functionality being tested by Assert.
>
> That's not how NUnit interprets a return. It takes it as a success
> and counts the method in the successful test cases.

Right.

> However, you already suggested a special exception, which would
> be the sort of indication I'm asking for.

I envision the exception being eaten by NUnit, and not being passed
back up through the GUI or to the user... there might be a case to be
made here, but I think silently succeeding fits best with the theory
of Theories. :-)

> > > >   Do you think it's worth having?
> > >
> > > As part of a full-fledged Theory implementation, Yes.
> > > As a separate thing, I can't see much value.
> >
> > I think it could be useful in the context of IteratedTest,
> > for example, you could generate random variables to be
> > returned from your IEnumeration... but not have it fail
> > should it generate a 0 randomly.
> > If you had it, I think you would come up with other reasons
> > that it might be useful... Without some data-driven
> > methodology, it might not have a whole lot of value except
> > that Tests function as documentation, and the Assume syntax
> > further clarifies what the Test means for human consumption.
>
> My problem is that the meaning of the Syntax is not what a
> normal human (at least I) thinks it should mean. Taken alone,
> Assume seems to say either "you don't have to check for this"
> or "it's an error if you get a zero value".

The word comes from the Theory paper. If you can think of a different
word, like maybe Precondition.That(...) that works better, I'm ok with
that. I don't like that Assert and Assume start with the same three
letters from an intellisense point of view anyway.

> Taken as a part of the statement of a Theory, it can have
> a different meaning, which makes sense in that context. It's
> a subtle distinction, but a real one I think.

The BDD folk have made a lot out of a pretty subtle thing, so paying
attention to the words used is clearly very important to some people.

> I do (and did) understand how this would be a useful feature
> but would rather not be driven by expediency. Why not use
> some other verb than Assume, saving it for use in the
> context of Theories? Alternatively, why are you generating
> random data that includes invalid values. :-)

Because it's easier to generate random values without thinking about
what might be legal in a particular context. That is, you can more
easily generate random values in a general way if you don't have to
worry about the specifics of a particular test... I'm usually a
generalizer, so I tend to pay attention to such issues earlier on that
maybe I should, YAGNI and all...

-Kelly

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