Here's an example of one of my multiple-result behaviours from my sudoku
solver:
public class IveGotItSoYouCantHaveItBehaviour extends UsingMatchers {
public void shouldReducePotentialsForEachDefinite() {
Niner niner = new Niner(createCells("5671234.8"));
Result result = new IveGotItSoYouCantHaveIt().applyTo(niner);
ensureThat(niner.toString(), eq("567123498"));
ensureThat(result, eq(Result.DEFINITE));
}
The code simply isn't valuable if it doesn't do both things:
* define the digit in the niner (a column, row or 3x3 square)
* report that the result was a newly defined digit (as opposed to a change
in potential digits, or no change at all).
If it does one without the other, I don't care about that piece of code,
or its behaviour. It isn't valuable to my Strategist, which uses it,
unless the Strategist knows whether to continue or not.
I like 'one intent'; I prefer phrasing it as 'one valuable thing'. I don't
like 'one assertion' blindly applied. YMMV.
Cheers,
Liz.
"Michael Hunger" <[EMAIL PROTECTED]> wrote on 13/07/2007 00:23:16:
> I'm just reading xUnit Test Patterns by Gerard Meszaros, there the one
> assertion per method is softened by the fact that one could and should
> create custom assertion methods (extract method) to assert complex
state.
>
> Please keep in mind the difference of asserting state or behaviour as
> JBehaeve aims to. When asserting state the fail fast approach is often
> useful as the assertions are placed in an order that shows their
> dependency. Many assertions rely on the previous ones in order not to
> generate Runtime Exceptions. So it is like the shortcut expression
> evaluation of e.g. the and operator. You can rely on the fact that only
> the expressions are evaluated that define the outcome of the whole
> expression.
>
> But if you _know_ that your assertions work in any order and with no
> prerequisites/preconditions an allOf or checkAll operator would indeed
be
> very useful. Perhaps it could handle the different matchers so that
> Runtime exceptions are also caught and reported as kind of the
> aftereffects of a previous failure.
>
> Thanks to Mauro for all the recent work.
>
> Michael
>
> On Fri, July 13, 2007 12:45 am, Shane Duan wrote:
> > I was reading this post
> >
(http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html).
> > I agree that one assertion per test is nice but the overhead is big,
> > not to mention you need to figure out a way to show that three methods
are
> > related to the same thing.
> >
> > Then it hit me, maybe we can have both?
> >
> >
> > The problem with multiple assertion is that it stops at the first
> > failure. But that was with JUnit, JBehave has its own framework!
> >
> > We could change the and() behavior (or create another method like and)
> > that calls into ALL assertions and generate a comprehensive error
message.
> >
> > So
> >
> >
> > ...
> > ensureThat(phoneNumber, and( areaCodeIs('738'), phoneNumberIs('233'),
> > extentionIs('333'))
> >
> > ...
> >
> >
> > now give:
> >
> > failed * area code should be '738' but was null
> > * phone number should be '233' but was '738'
> > * extension should be '333' but was null
> >
> >
> > Thoughts?
> >
> >
> > --
> > Shane
> > http://www.shaneduan.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
