mockobjects-java-dev

[MO-java-dev] [dynamic] Question about MethodMap.verify()

[Barry K. <bk...@in...>]

I have the following test snippet:

        Mock mockConnection = new Mock(Connection.class);
        Mock mockSelectStatement = new Mock(PreparedStatement.class);
        Mock mockUpdateStatement = new Mock(PreparedStatement.class);
        CallSequence prepareStatementCalls = new CallSequence();

        
prepareStatementCalls.expectReturn(HighLowIdentityGenerator.SELECT_NEXT_BLOCK_STATEMENT, 
mockSelectStatement.proxy());
        
prepareStatementCalls.expectReturn(HighLowIdentityGenerator.UPDATE_NEXT_BLOCK_STATEMENT, 
mockUpdateStatement.proxy());
        mockConnection.expect("prepareStatement", prepareStatementCalls);
        mockSelectStatement.expectAndReturn("executeQuery", null);
        mockUpdateStatement.expectVoid("execute");

        generator.setIdentity(mockDatabaseContext, object);

        mockConnection.verify();               // This succeeds, I would 
expect it fail
        prepareStatementCalls.verify();      // This fails, as I expect
        assertEquals(1, object.getId());

It seems that the MethodMap only checks that the method of the name was 
invoked, but does not take into account that the MockCall for that 
method was a CallSequence. Should MethodMap be delegating to MockCall 
for [part of?] its verify?

-bk

Re: [MO-java-dev] [dynamic] Question about MethodMap.verify()

[Nat P. <nat...@b1...>]

If you use decorators around MockCall (e.g. CallSequence or a CallCount)
you have to explcitly verify those objects yourself.

Hmm... perhaps the Mock class should test to see if the MockCall is
Verifiable and then automatically verify it if it is.  What do people
think?

Cheers,
	Nat. 

On Thu, 2002-11-21 at 17:14, Barry Kaplan wrote:
> I have the following test snippet:
> 
>         Mock mockConnection = new Mock(Connection.class);
>         Mock mockSelectStatement = new Mock(PreparedStatement.class);
>         Mock mockUpdateStatement = new Mock(PreparedStatement.class);
>         CallSequence prepareStatementCalls = new CallSequence();
> 
>         
> prepareStatementCalls.expectReturn(HighLowIdentityGenerator.SELECT_NEXT_BLOCK_STATEMENT, 
> mockSelectStatement.proxy());
>         
> prepareStatementCalls.expectReturn(HighLowIdentityGenerator.UPDATE_NEXT_BLOCK_STATEMENT, 
> mockUpdateStatement.proxy());
>         mockConnection.expect("prepareStatement", prepareStatementCalls);
>         mockSelectStatement.expectAndReturn("executeQuery", null);
>         mockUpdateStatement.expectVoid("execute");
> 
>         generator.setIdentity(mockDatabaseContext, object);
> 
>         mockConnection.verify();               // This succeeds, I would 
> expect it fail
>         prepareStatementCalls.verify();      // This fails, as I expect
>         assertEquals(1, object.getId());
> 
> It seems that the MethodMap only checks that the method of the name was 
> invoked, but does not take into account that the MockCall for that 
> method was a CallSequence. Should MethodMap be delegating to MockCall 
> for [part of?] its verify?
> 
> -bk
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
Nat Pryce <nat...@b1...>
B13media

Re: [MO-java-dev] [dynamic] Question about MethodMap.verify()

[Barry K. <bk...@in...>]

Nat Pryce wrote:

>If you use decorators around MockCall (e.g. CallSequence or a CallCount)
>you have to explcitly verify those objects yourself.
>
>Hmm... perhaps the Mock class should test to see if the MockCall is
>Verifiable and then automatically verify it if it is.  What do people
>think?
>
>  
>
+1

Re: [MO-java-dev] [dynamic] Question about MethodMap.verify()

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

If we're going this route, then we should make MockCall a Verifiable and 
verify everything, even if it doesn't do anything.

I'm concerned about the duplication of overloaded methods between Mock 
and CallSequence. It feels like we haven't teased out all the concepts. 
One solution may be to make them both derive from some kind of template 
class. I'm not sure that Mock should extend Assert, it's usually the 
test case that does that.

I've done some tweaking and I'll rename dynamic.P to C for consistency, 
should it be in the constraint package?

S.

Barry Kaplan wrote:
> Nat Pryce wrote:
> 
>> If you use decorators around MockCall (e.g. CallSequence or a CallCount)
>> you have to explcitly verify those objects yourself.
>>
>> Hmm... perhaps the Mock class should test to see if the MockCall is
>> Verifiable and then automatically verify it if it is.  What do people
>> think?