Steve Freeman-2 wrote:
>
>
> It's partly my fault for writing a piece ages ago that suggesting mocking
> out the jdbc interfaces...
>
> If you're calling JDBC yourself, it's probably still worth writing a small
> number of tests to ensure that you're managing connections and handling
> errors correctly, and then, like Nat says, test against an instance of the
> real thing. Once again, however, the important thing is to TDD an
> interface that describes what you want from persistent storage.
>
> S.
>
> On 26 September, 2005, Nat Pryce wrote:
>> I wouldn't suggest mocking the java(x).sql classes directly. Use
>> mocks to guide the design of an interface that defines how your
>> classes access a persistent store. Implement that store using JDBC and
>> test that implementation in integration tests. The exact behaviour of
>> code that uses JDBC depends on the driver and database, and so it must
>> be tested in combination with those components.
>
>
>




Returning String object as Stub (alternative to StubSequence with String):

Inside JMock Test, If you want to return the String object as return value
(in case where number of consecutive calls are more than four time. so that
you can't use onConsecutiveCalls() method directly )

mockHttpRequest.expects(atLeastOnce()).method("getAttribute").with(eq("context-key")).
       
     will(onConsecutiveCalls( new Stub[]{

         returnValue("key-1234"),          
         
         returnValue("key-1234"),

         returnValue("key-123456"),

         returnValue("key-123456"),          

         returnValue("key-12345678"),

         returnValue("key-12345678")  // and so on
     
         })
     );










--
Sent from the jMock - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email