[MO-java-users] Re: [MO-java-dev] Release 0.07?

[Steve F. <ste...@m3...>]

Happy to have you on board.

Pattern 2 is the correct one. The idea of setting expectations is so 
that the test can fail at the right time, when the actual event occurs. 
We can't do that if you don't specify your requirements before you start.

We know that the javadoc is a mess, but we talk about this pattern at 
least in the Endo-testing paper. Is it not clear?

S

Immanuel, Gidado-Yisa wrote:

>(Appologies if this should go to the user list, but
>that list has been dormant for a little while, so
>I'm headed straight to the source)
>
>This has taken me about an 1 1/2 to figure out (thank
>goodness for the code).  In my test case I have:
>
>  1.    handler.log(val);
>  2.    mock.setExpectedLogMessage(val);
>  3.    mock.verify();
>
>where the handler knows about the mock.  What happens is
>that line 1 eventually calls mock.log() which then calls
>mock.logMessage.setActual().  setActual looks to see if
>it should verify...finds no expectations...so skips it.
>
>Line 2 sets the expected value which eventually calls
>ExpectationValue.setExpected() which calls
>AbstractExpectation.setHasExpectations() which does the
>not so obvious:
>
>   AbstractExpectation.clearActual()
>
>So Line 2 ends up clearing whatever is set in Line 1.  The
>only usage pattern that works is to setExpected() before setActual():
>
>  1.    mock.setExpectedLogMessage(val);
>  2.    handler.log(val);
>  3.    mock.verify();
>
>This was not clear anywhere in the articles or javadoc.  Perhaps
>you could add this to the FAQ page.  I assume there is a very
>good reason why clearActual() is necessary in
>setHasExpectations()...I'm very new to all this, so if you don't
>mind educating me a little, I would love to know.
>
>Thanks,
>Gidado
>
>  
>