Nabble - jMock - User

Re: Mocking Static Methods using JMock

2009-12-01T01:50:29Z

Thanks for your quick reply Steve.
The above code snippet was just a simple example. The code that I am working on contains complex logic in the static function.

Steve Freeman-2 wrote:

We don't support mocking of static methods since there is almost
always a better way. That might mean testing it directly in an
integration test or writing a thin layer above the static method and
testing against /that/.

If your method is as simple as getName() it might be better to just
call the method.
S.

On 1 Dec 2009, at 03:37, Siddhi B <borkar.siddhi@gmail.com> wrote:
> Hi,
>
> I need a way of mocking a static class using JMock. Consider the
> following
> code snippet.
>
> public class A {
> void functionX() {
> String name = ClassB.getName(); // Static function
> }
> }
>
> public class ClassB {
> static String getName() {
> return 'ABC'
> }
> }
>
> I need a way of mocking the static function 'getName'.Please note
> that I do
> not have rights to modify the legacy code.
>
> Any help would be highly appreciated.
>
> Thanks,
> Siddhi
> --
> View this message in context: http://old.nabble.com/Mocking-Static-Methods-using-JMock-tp26585954p26585954.html
> Sent from the jMock - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>

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

http://xircles.codehaus.org/manage_email

Re: Mocking Static Methods using JMock

2009-11-30T23:51:52Z

We don't support mocking of static methods since there is almost
always a better way. That might mean testing it directly in an
integration test or writing a thin layer above the static method and
testing against /that/.

If your method is as simple as getName() it might be better to just
call the method.
S.

On 1 Dec 2009, at 03:37, Siddhi B <borkar.siddhi@...> wrote:

> Hi,
>
> I need a way of mocking a static class using JMock. Consider the
> following
> code snippet.
>
> public class A {
> void functionX() {
> String name = ClassB.getName(); // Static function
> }
> }
>
> public class ClassB {
> static String getName() {
> return 'ABC'
> }
> }
>
> I need a way of mocking the static function 'getName'.Please note
> that I do
> not have rights to modify the legacy code.
>
> Any help would be highly appreciated.
>
> Thanks,
> Siddhi
> --
> View this message in context: http://old.nabble.com/Mocking-Static-Methods-using-JMock-tp26585954p26585954.html
> Sent from the jMock - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>

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

http://xircles.codehaus.org/manage_email

Mocking Static Methods using JMock

2009-11-30T19:37:33Z

Hi,

I need a way of mocking a static class using JMock. Consider the following code snippet.

public class A {
void functionX() {
String name = ClassB.getName(); // Static function
}
}

public class ClassB {
static String getName() {
return 'ABC'
}
}

I need a way of mocking the static function 'getName'.Please note that I do not have rights to modify the legacy code.

Any help would be highly appreciated.

Thanks,
Siddhi

Re: Peculiar expectation error

2009-11-30T16:28:11Z

Problem solved. Moved test fixture to @BeforeMethod annotated method and create
new Mockery object before any fixture code executed.

Cheers,
Sam

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

http://xircles.codehaus.org/manage_email

Re: Peculiar expectation error

2009-11-30T15:28:35Z

Steve,

We're using TestNG here and perhaps my lack of familiarity with it is causing
some issues. However if you could shed some light on the following issue I think
that might go some way towards solving my other issue. I've been receiving the
following error:

java.lang.IllegalArgumentException: a mock with name "object name" already exists

As a work around I've been putting my test fixture in a method called setUp
which was annotated with @BeforeClass. I thought @BeforeMethod annotation would
be more appropriate but that didn't prevent the above error. But given that a
new context object should be created for each test in a test class, I should not
receive the above message, correct?

I'm using the following code to set up the each unit test class (yes, I'm
mocking concrete classes) :

private Mockery context = new Mockery() {{
setImposteriser(ClassImposteriser.INSTANCE);
}};

Again, my understanding is that if I have N tests in a class, each test should
receive its own context object. If that is correct then I should only receive
the above error if within the same test I create two or more mock objects with
the same identifier?

Thanks for your help.
Sam

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

http://xircles.codehaus.org/manage_email

Re: Peculiar expectation error

2009-11-30T15:08:22Z

Hi Steve,

Here's an example - there's nothing untoward about it as far as I can tell:

public void isForCMAndTotalCommissionGreaterThanMaxCommissionAllowed() {
float expectedCommission = 60f;
final float baseCostPlusTaxValue = 300.0f;
final float maxAllowableCommission = 70.0f;
final float baseCost = 254.0f;
final float retailPerSegmentAmount = 5.0f;
final int numberOfSegmentsFlown = 4;

context.checking(new Expectations() {{
allowing(clientServices);
oneOf(itin).isOpaque(); will(returnValue(false));
oneOf(carrier).isUnknown(); will(returnValue(false));
oneOf(calculator).calculate(itin, carrier);
will(returnValue(commissionVO));
oneOf(commissionVO).getBaseCommission();
will(returnValue(10.0f));
oneOf(commissionVO).getPlatingCarrier();
will(returnValue(carrier));
}});

airCommCalc = new AirCommissionCalculator(baseCommissionCalc, commission);
assertEquals(expectedCommission,
this.airCommCalc.calculate(itin, carrier, true));
}

Cheers,
Sam

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

http://xircles.codehaus.org/manage_email

Re: Peculiar expectation error

2009-11-30T14:11:39Z

Odd. It implies there's something static going on either in the code or the tests.

What do your expectations look like?

S.

On 30 Nov 2009, at 22:09, Sam wrote:

> I'm experiencing a peculiar error with the expectations in my unit tests - it's
> as if expectations from previously run unit tests (run in the same process) are
> being 'remembered' and included in the expectations of other tests. Thus the
> unit tests for an entire unit test class are failing when executed as a whole
> but pass when executed individually - i.e. expectations from other tests cannot
> bleed over into the current, individual test. Now this shouldn't happen because
> of the creation of the anonymous inner class, correct?:
>
> context.checking(new Expectations() {{
> expectation1;
> expectation2;
> }});
>
> I really have no idea what's going on - hopefully someone else does!

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

Peculiar expectation error

2009-11-30T14:09:06Z

Hi,

I'm experiencing a peculiar error with the expectations in my unit tests - it's
as if expectations from previously run unit tests (run in the same process) are
being 'remembered' and included in the expectations of other tests. Thus the
unit tests for an entire unit test class are failing when executed as a whole
but pass when executed individually - i.e. expectations from other tests cannot
bleed over into the current, individual test. Now this shouldn't happen because
of the creation of the anonymous inner class, correct?:

context.checking(new Expectations() {{
expectation1;
expectation2;
}});

I really have no idea what's going on - hopefully someone else does!

Thanks,
Sam

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

http://xircles.codehaus.org/manage_email

Re: JMock doesn't seem to be invoked when mocking a concrete class

2009-11-23T03:07:30Z

well, you're partially right. The problem is that the VirtualInstanceContextHolder contains a private constructor,an the way that class is used is by invoking a
VirtualInstanceContextHolder.getContext() which would return a VirtualInstanceContext object.
The bottom line is: I want to return a DTOFactory from my metod getDTOFactory in the Service class. Can I do that without setting up mock of all the things that the getDTOFactory is using?

Regards,
Viggo

On Mon, Nov 23, 2009 at 11:15 AM, Julian Hall <jules@...> wrote:

Viggo Navarsete wrote:

I'm having a unit test which is supposed to test a Service. The Service in turn calls another class. I want to mock the invocations to the class the Service uses.

MyTest-->Service-->AConcreteClass

So, MyTest executes a method on Service, which in turn execute a method on a concrete class, AConcreteClass.
I want to mock the execution on the AConcreteClass in Service, but it doesn't seem to mock it.

Some code:

************************************************************************************************************************************************************************************************
MyTest:

@Test
public void testDataLoad() throws Exception {

Mockery context = new Mockery() {{
setImposteriser( ClassImposteriser.INSTANCE );
}};

final VirtualInstanceContextHolder vich = context.mock( VirtualInstanceContextHolder.class );
final VirtualInstanceContext vic = context.mock( VirtualInstanceContext.class );
final ApplicationContext ac = context.mock( ApplicationContext.class );
final Persistence persistence = context.mock( Persistence.class );
final Map<String, String> emMap = new HashMap<String, String>();

context.checking( new Expectations() {{
allowing( vich );
will( returnValue( new VirtualInstanceContext()));

Shouldn't this be returning vic?

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

http://xircles.codehaus.org/manage_email

--
Viggo Navarsete
Senior Developer
TraceTracker AS

Øvre Slottsgt.4, 4th floor, N-0157 Oslo, Norway
Central number: +47 47 70 44 00
Direct number: +47 92 43 14 90
E-mail: viggo@...

TraceTracker was selected Technology Pioneer 2009 by the World Economic Forum.

This is a confidential business communication. If you have received it in error please notify the sender and delete it. Any unauthorized use of this communication is prohibited.Copyright 2009 TraceTracker AS, Oslo - Norway

RE [jmock-user] JMock doesn't seem to be invoked when mocking a concrete class

2009-11-23T03:01:49Z

Looks like you have a static method (VirtualInstanceContextHolder.getContext()), and you can't mock static methods because they're not polymorphic.
There are some hacks to get around this (though the ideal solution is to refactor so vic is injected - i.e. passed as an argument into either the service's constructor or the method call).
If you can set the singleton value returned by VirtualInstanceContextHolder.getContext() to vic, your problem is solved (it seems to be set to null in your test, currently). Or you could move the static call into
a protected method of the service (call it "getVIContext()" or something like that) and then run your test on a subclass of the service which overrides this method to return an instance
received in its constructor or a setter, where you inject the object vic in your test code.
-Alan

Viggo Navarsete <viggo@...>

23/11/2009 10:52

Veuillez répondre à
user@...

A	user@...
cc
Objet	[jmock-user] JMock doesn't seem to be invoked when mocking a concrete class

I'm having a unit test which is supposed to test a Service. The Service in turn calls another class. I want to mock the invocations to the class the Service uses.

MyTest-->Service-->AConcreteClass

So, MyTest executes a method on Service, which in turn execute a method on a concrete class, AConcreteClass.
I want to mock the execution on the AConcreteClass in Service, but it doesn't seem to mock it.

Some code:

************************************************************************************************************************************************************************************************
MyTest:

@Test
public void testDataLoad() throws Exception {

        Mockery context = new Mockery() {{
            setImposteriser( ClassImposteriser.INSTANCE );
        }};

        final VirtualInstanceContextHolder vich = context.mock( VirtualInstanceContextHolder.class );
        final VirtualInstanceContext vic = context.mock( VirtualInstanceContext.class );
        final ApplicationContext ac = context.mock( ApplicationContext.class );
        final Persistence persistence = context.mock( Persistence.class );
        final Map<String, String> emMap = new HashMap<String, String>();

        context.checking( new Expectations() {{
            allowing( vich );
                will( returnValue( new VirtualInstanceContext()));
            allowing( vic ).getApplicationContext();
                will( returnValue( new AutowiringXmlWebApplicationContext() ));
            allowing( ac ).getParent();
            allowing( ac ).getBean( "SecureDTOFactory" );
                will( returnValue( new DTOFactory() ) );
            allowing( persistence).createEntityManagerFactory( "epcisTIXPU", emMap );
                will( returnValue( Persistence.createEntityManagerFactory( "epcisTIXPU" ).createEntityManager()));
        }});

       results = service.simpleEventQuery(new QueryParams()); // execute the actual method on Service

************************************************************************************************************************************************************************************************
Service:

   public List<EventDetailsDTO> simpleEventQuery( QueryParams queryParam) {

       DTOFactory dtoFactory = getDTOFactory(); // I want to mock the method invocations in the private getDTOFactory!!
   }

    private DTOFactory getDTOFactory() {
        VirtualInstanceContext vic = VirtualInstanceContextHolder.getContext(); // I get back an object here
        ApplicationContext ac = vic.getApplicationContext(); // This one returns null and is what I want to figure out why!!
        ApplicationContext acParent = ac.getParent();
        DTOFactory dtoFactory = (DTOFactory) acParent.getBean( "SecureDTOFactory" );
        return dtoFactory;
    }

My environment:
- Maven 2.0.9
- JUnit 4.4
- JDK 1.6.0_16

Re: JMock doesn't seem to be invoked when mocking a concrete class

2009-11-23T02:15:41Z

Viggo Navarsete wrote:

> I'm having a unit test which is supposed to test a Service. The
> Service in turn calls another class. I want to mock the invocations to
> the class the Service uses.
>
> MyTest-->Service-->AConcreteClass
>
> So, MyTest executes a method on Service, which in turn execute a
> method on a concrete class, AConcreteClass.
> I want to mock the execution on the AConcreteClass in Service, but it
> doesn't seem to mock it.
>
> Some code:
>
> ************************************************************************************************************************************************************************************************
> MyTest:
>
> @Test
> public void testDataLoad() throws Exception {
>
> Mockery context = new Mockery() {{
> setImposteriser( ClassImposteriser.INSTANCE );
> }};
>
> final VirtualInstanceContextHolder vich = context.mock(
> VirtualInstanceContextHolder.class );
> final VirtualInstanceContext vic = context.mock(
> VirtualInstanceContext.class );
> final ApplicationContext ac = context.mock(
> ApplicationContext.class );
> final Persistence persistence = context.mock( Persistence.class );
> final Map<String, String> emMap = new HashMap<String, String>();
>
> context.checking( new Expectations() {{
> allowing( vich );
> will( returnValue( new VirtualInstanceContext()));

Shouldn't this be returning vic?

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

http://xircles.codehaus.org/manage_email

JMock doesn't seem to be invoked when mocking a concrete class

2009-11-23T01:51:46Z

Checkstyle check for @RunWith(JMock)

2009-11-22T16:33:34Z

Hi

I'm thinking of writing a Checkstyle custom check that checks a class containing
a Mockery field is annotated with @RunWith(JMock).

Can anyone think of a scenario where you might want a Mockery field and not use
the JMock TestRunner implementation?

Thanks

S
--
Stephen Smith
http://www.stephen-smith.co.uk/

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

http://xircles.codehaus.org/manage_email

Re: error message with custom matcher

2009-11-20T06:59:10Z

More...

You might also want to look at samePropertyValuesAs().

And you don't need to declare @Factory on the factory method, that's just for code generating the Matchers class.

On 20 Nov 2009, at 06:07, John Sanda wrote:

> I writing a test using a custom matcher. The custom matcher seems to be working, but the error message in the failure seems off. Here is roughly what my test looks like,

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

Re: error message with custom matcher

2009-11-20T06:56:13Z

describeTo() describes the /matcher/, what you expected not what you got.

to report the actual value, you need to implement a mismatch description. Look at TypeSafeDiagnosingMatche. If you can't find it, you probably need to upgrade to the next version of Hamcrest.

S

On 20 Nov 2009, at 06:07, John Sanda wrote:
> I writing a test using a custom matcher. The custom matcher seems to be working, but the error message in the failure seems off. Here is roughly what my test looks like,

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

error message with custom matcher

2009-11-20T06:07:04Z

I writing a test using a custom matcher. The custom matcher seems to be working, but the error message in the failure seems off. Here is roughly what my test looks like,

ConfigurationFacet facet = context.mock(ConfigurationFacet.class)
ConfigurationService configService = context.mock(ConfigurationService.class);

context.checking(new Expectations() {{
    oneOf(facet).updateResourceConfiguration(with(any(ConfigurationUpdateReport.class)));
    atLeast(1).of(configService).completeConfigurationUpdate(with(matchingResponse(expectedResponse)));
}});

expectedResponse is an instance of ConfigurationUpdateResponse and matchingResponse is my custom matcher that does a property comparison. The code for it is,

public class ConfigurationUpdateResponseMatcher extends TypeSafeMatcher<ConfigurationUpdateResponse> {
        @Factory
        public static Matcher<ConfigurationUpdateResponse> matchingResponse(ConfigurationUpdateResponse expected) {
            return new ConfigurationUpdateResponseMatcher(expected);
        }

        private ConfigurationUpdateResponse expected;

        public ConfigurationUpdateResponseMatcher(ConfigurationUpdateResponse response) {
            expected = response;
        }

        public boolean matchesSafely(ConfigurationUpdateResponse actual) {
            return propertyEquals(expected.getConfiguration(), actual.getConfiguration()) &&
                      propertyEquals(expected.getConfigurationUpdateId(), actual.getConfigurationUpdateId()) &&
                      propertyEquals(expected.getErrorMessage(), actual.getErrorMessage()) &&
                  propertyEquals(expected.getStatus(), actual.getStatus());
        }

        private boolean propertyEquals(Object expected, Object actual) {
            if (expected == null && actual == null) {
                return true;
            }

            if (expected == null && actual != null) {
                return false;
            }
            return expected.equals(actual);
        }

        public void describeTo(Description description) {
            description.appendText("A " + ConfigurationUpdateResponse.class.getSimpleName() + " matching " +
                    expected);
        }
}

I thought that the error message I would see when my custom matcher returns false would be the description it creates in its describeTo() method. Instead, I see,

un
Expected :ConfigurationUpdateResponse[configurationUpdateId=-1, ConfigurationUpdateStatus=Failure, configuration=Configuration[id=0]]
Actual   :org.rhq.core.pluginapi.configuration.ConfigurationUpdateReport@50269997
)

I used values to trigger the failure as a way to verify that my custom matcher is working, but the error reporting is wrong. The object it is reporting as expected appears to be from,

oneOf(facet).updateResourceConfiguration(with(any(ConfigurationUpdateReport.class)))

but the custom matcher takes an instance of ConfigurationUpdateResponse. Is there something that I can do to alter the error message that is reported?

Thanks

- John

Re: javax.xml package

2009-11-17T17:29:44Z

Thanks Steve, appreciate it.

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

http://xircles.codehaus.org/manage_email

Re: Advice on testing my classes that has many third party API calls.

2009-11-17T02:05:22Z

Steve Freeman-2 wrote:

On 27 Oct 2009, at 10:36, LadyCoconut wrote:
> My questions are:
>
> 1. in my test I am using the matchers with(any(OpertionOptions.class),
> with(any(Profile.class) and such....should I be mocking these concrete
> classes using the ClassImposteriser and setting them up and checking
> the
> exact expectations of these? It feels a bit wrong. All I want to
> test is
> that a call to the service is made and that I get back an expected
> type with
> some parameters in it?

You want to check, for example, that the ObjectIdentitySet has been
set up correctly? You could write a more precise matcher that checks
the values within the ObjectIdSet that was passed in. Something like:

oneOf(objectService).get(with(objectIdentitySetWithId(1)), ...

If you just want to let the call go through, then the any() clauses
are fine--that's your intention. You can simplify it further, if
there's only one call to an object:

allowing(objectService); will(returnValue(dataPackage));

if that's all you care about. (Remember: Stub Queries, Expect Actions)

> 2. Should I be spending my time skinning and wrapping the API for
> testing?
> As its rather a small project at the moment, I managed to create a
> stub
> service initially that returns some duff data.

That depends :) At the least, I'd have some kind of interface in my
domain code that protected me from the library, so there were no
references.

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

Thanks for the advice and the reply.
Got your book in the post yesterday, looking forward to reading it.

Re: javax.xml package

2009-11-16T03:04:11Z

Sorry for the delay in responding. My first instinct is to write my domain code against interfaces that describes what I want from JAXB, which I can mock in my tests. What happens after that depends on what I want to prove and how hard it is to work with the third-party library. For a case like this, it might be best to test the adaptor code directly against the jaxb library and see what XML comes out. Whether any of that testing involves mocks depends on how complex the adaption is and how accommodating the design of java.xml is.

S.

On 13 Nov 2009, at 22:48, Sam wrote:
> I'm writing code which uses the javax.xml package. Is the correct approach, and
> I use the phrase lightly, that I create domain appropriate interfaces and the
> relevant adaptors for the package? Or should I use the api directly and mock
> classes such as JAXBContext.java for testing purposes?

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

javax.xml package

2009-11-13T14:48:50Z

Hi,

I'm writing code which uses the javax.xml package. Is the correct approach, and
I use the phrase lightly, that I create domain appropriate interfaces and the
relevant adaptors for the package? Or should I use the api directly and mock
classes such as JAXBContext.java for testing purposes?

Any thoughts would be greatly appreciated.

Cheers,
Sam

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

http://xircles.codehaus.org/manage_email

Ability to use jMock through the Rule mechanism

2009-11-08T14:26:27Z

Hello everybody!

As all of you probably know a new feature, Rule mechanism, has been
added to JUnit 4.7.
After the discussion with David Saff (main JUnit contributor) and Nat
Pryce it comes out that it is better to use jMock through the Rule
mechanism and not through the runner:

public class JMockRuleTest {
@Rule public Verifier jmock = new JMockVerifier();
}

This approach will allow to use jMock with a custom JUnit runner like
Theories or your favorite one.

I'm going to implement this feature and want to know your valuable
opinion on what kind of API you expect.
Personally I think that this new API will be similar to the current
Mockery's one.

I've already created a new issue in JIRA -
http://jira.codehaus.org/browse/JMOCK-237

--
Best regards,
Ivan Yatskevich

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

http://xircles.codehaus.org/manage_email

Re: Advice on testing my classes that has many third party API calls.

2009-10-30T07:33:28Z

On 27 Oct 2009, at 10:36, LadyCoconut wrote:

> My questions are:
>
> 1. in my test I am using the matchers with(any(OpertionOptions.class),
> with(any(Profile.class) and such....should I be mocking these concrete
> classes using the ClassImposteriser and setting them up and checking
> the
> exact expectations of these? It feels a bit wrong. All I want to
> test is
> that a call to the service is made and that I get back an expected
> type with
> some parameters in it?

You want to check, for example, that the ObjectIdentitySet has been
set up correctly? You could write a more precise matcher that checks
the values within the ObjectIdSet that was passed in. Something like:

oneOf(objectService).get(with(objectIdentitySetWithId(1)), ...

If you just want to let the call go through, then the any() clauses
are fine--that's your intention. You can simplify it further, if
there's only one call to an object:

allowing(objectService); will(returnValue(dataPackage));

if that's all you care about. (Remember: Stub Queries, Expect Actions)

> 2. Should I be spending my time skinning and wrapping the API for
> testing?
> As its rather a small project at the moment, I managed to create a
> stub
> service initially that returns some duff data.

That depends :) At the least, I'd have some kind of interface in my
domain code that protected me from the library, so there were no
references.

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-28T11:27:52Z

> Julian Hall wrote:
>> isaiah perumalla wrote:
>>> Jmock will highlight badly designed communication protocols
>>> between object under test and its collaborators. On the other
>>> hand, frameworks like mockito by default ignore all calls between
>>> the object under test and it's mocked collaborator(s) and only
>>> verifies calls you explicitly specify.
>> There is, of course, a halfway ground to consider. When I'm
>> working in .NET, I tend to use Rhino.Mocks. This has the
>> interesting facility that if you call MockRepository.CreateMock to
>> create your mock, you end up with something that behaves like JMock
>> does, but if you call MockRepository.DynamicMock you end up with a
>> stub implementation that ignores unexpected calls, or you can use
>> MockRepository.PartialMock when mocking a concrete class to get a
>> stub that passes calls to the original implementation by default.
>> It's still a "set expectations before running your code" style of
>> interaction rather than the "verify what happened after you've done
>> it" style you use with Mockito, but it's a little more flexible
>> than JMock.

Actually, JMock does the first two without have to choose when
declaring the mock. The third is just a bad idea unless it's an
emergency :)

S.

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-28T10:37:18Z

PowerMock works a bit like this. It allows you to create partial mocks
and to mock static objects. Unfortunately if you're testing spring
managers or controllers there are issues to workaround with bean
definitions. It has interfaces to mockito and EasyMock also.

Julian Hall wrote:

> isaiah perumalla wrote:
>> Jmock will highlight badly designed communication protocols between
>> object under test and its collaborators. On the other hand,
>> frameworks like mockito by default ignore all calls between the
>> object under test and it's mocked collaborator(s) and only verifies
>> calls you explicitly specify.
> There is, of course, a halfway ground to consider. When I'm working
> in .NET, I tend to use Rhino.Mocks. This has the interesting facility
> that if you call MockRepository.CreateMock to create your mock, you
> end up with something that behaves like JMock does, but if you call
> MockRepository.DynamicMock you end up with a stub implementation that
> ignores unexpected calls, or you can use MockRepository.PartialMock
> when mocking a concrete class to get a stub that passes calls to the
> original implementation by default. It's still a "set expectations
> before running your code" style of interaction rather than the "verify
> what happened after you've done it" style you use with Mockito, but
> it's a little more flexible than JMock.
>
> (The API's also a little cleaner, but that's because .NET allows a
> cleaner API than Java does, largely due to having proper generic types)
>
>
> ---------------------------------------------------------------------
> 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

Advice on testing my classes that has many third party API calls.

2009-10-27T03:36:33Z

Hello Everyone,

I have some experience in jMock. Currently using it with JUnit 3 (long story).

Anyway, I've had to develop a little application that depends heavily on third party libraries. The libraries are basically used for pulling documents from a repository. Some of the classes have interfaces (not many) and there are many concrete classes.

Assume the following test code:

final IObjectService objectService = mock(IObjectService.class);

final DataPackage dataPackage = createDataPackage();

checking(new Expectations() {{
oneOf (serviceContext).getIdentityCount(); will(returnValue(1));
oneOf (serviceContext).setProfile(with(any(Profile.class)));
oneOf (serviceFactory).getLocalService(with(IObjectService.class),
with(serviceContext)); will(returnValue(objectService));

oneOf (objectService).get(with(any(ObjectIdentitySet.class)),
with(any(OperationOptions.class))); will(returnValue(dataPackage));
}});

Now here is the code that it is testing (bit ugly) but bear with me...

if(serviceContext.getIdentityCount() == 0) {
serviceContext.addIdentity(repositoryIdentity);
}

ObjectId id = new ObjectId(objectId);
ObjectIdentity<ObjectId> objectIdentity = new ObjectIdentity<ObjectId>(id, repositoryIdentity.getRepositoryName());

ObjectIdentitySet objectIdSet = new ObjectIdentitySet();
objectIdSet.addIdentity(objectIdentity);

ContentTransferProfile transferProfile = new ContentTransferProfile();
transferProfile.setTransferMode(ContentTransferMode.MTOM);
transferProfile.setCachedContentTransferAllowed(true);
transferProfile.setAsyncContentTransferAllowed(true);

serviceContext.setProfile(transferProfile);

IObjectService objectService = serviceFactory.getLocalService(IObjectService.class, serviceContext);

OperationOptions operationsOptions = getOperationsOptionsProfile();
DataPackage dataPackage = objectService.get(objectIdSet, operationsOptions);
Content content = dataPackage.getDataObjects().get(0).getContents().get(0); //check

My questions are:

1. in my test I am using the matchers with(any(OpertionOptions.class), with(any(Profile.class) and such....should I be mocking these concrete classes using the ClassImposteriser and setting them up and checking the exact expectations of these? It feels a bit wrong. All I want to test is that a call to the service is made and that I get back an expected type with some parameters in it?

2. Should I be spending my time skinning and wrapping the API for testing? As its rather a small project at the moment, I managed to create a stub service initially that returns some duff data.

Any thoughts would be welcome.

Regards

Re: Differences between jMock & Mockito

2009-10-26T06:51:29Z

With tests like this, there's not much difference, although both tests
could be made more compact. It's mostly stubbing, since there's no
external change in state. There's a bit of duplication in the mockito
version for the verification but, as you point out, it's not
interesting here. Even easymock could be made to work for these tests.

I think the differences (if any) will become more apparent when the
code deals in more behaviour than values. Here's an example from the
book (hope it doesn't get mangled by line-wrapping):

public class SniperLauncherTest {
private final States auctionState = context.states("auction state")
.startsAs("not joined");

@Test public void addsNewSniperToCollectorAndThenJoinsAuction() {
final String itemId = "item 123";
context.checking(new Expectations() {{
allowing(auctionHouse).auctionFor(itemId); will(returnValue
(auction));

oneOf(sniperCollector).addSniper(with(sniperForItem(item)));
when(auctionState.is("not
joined"));
oneOf(auction).addAuctionEventListener(with(sniperForItem
(itemId)));
when(auctionState.is("not
joined"));
one(auction).join(); then(auctionState.is("joined"));
}});

launcher.joinAuction(itemId);
}
}

which describes the relationships between a "launcher", an "auction",
and a "sniperCollector". This is about protocols between objects, not
just method calls, and maps nicely onto a state-transition diagram we
drew to describe these relationships. We don't need this all the time,
but when we do, we really do.

S.

On 25 Oct 2009, at 23:56, Neil Swingler wrote:
> I have just given myself a 30 minute crash course in jmock2 by
> converting one of jmock's very own unit tests to Mockito. OK I only
> chose the first test but I think it gives a flavour of the
> differences. The full compiling class is attached but here is the
> interesting bit. Personally I would probably skip the verify steps
> in the mockito version but kept them in for completeness.
> [...]

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 (0) 797 179 4105
M3P Limited. http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-26T00:50:09Z

Well here the stub part is being separated from the expectation part. I

think this is not a bad thing. As I said I would personally delete the

verification calls as they duplicate the checking done by the asserts at

the end anyway. I just left them in to demonstrate mockito.

- Neil

On Mon, 26 Oct 2009 07:05:14 +0000, Nat Pryce <nat.pryce@...> wrote:

> They look not too different apart from Mockito makes you duplicate

> expectations a bit.

>

> An interesting comparison might be a test that uses jMock's States

> mechanism to control ordering and vary the behaviour of mocked calls.

>

> --Nat

>

> On Sunday, October 25, 2009, Neil Swingler <neil@...> wrote:

>> I have just given myself a 30 minute crash course in jmock2 by

converting

>> one of jmock's very own unit tests to Mockito. OK I only chose the first

>> test but I think it gives a flavour of the differences. The full

>> compiling class is attached but here is the interesting bit. Personally

I

>> would probably skip the verify steps in the mockito version but kept

them

>> in for completeness.

>>

>>    public void testLoadsObjectThatIsNotCachedWithJmock() {

>>    Mockery context = new Mockery() {{

>>

>> setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);

>>    }};

>>    final Clock clock = context.mock(Clock.class);

>>    final ObjectLoader loader = context.mock(ObjectLoader.class,

>> "loader");

>>    ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

>>

>>    TimedCache cache = new TimedCache(loader, clock,

reloadPolicy);

>>    context.checking(new Expectations() {{

>>    allowing (clock).time(); will(returnValue(loadTime));

>>

>>    oneOf (loader).load("key1"); will(returnValue(VALUE1));

>>    oneOf (loader).load("key2"); will(returnValue(VALUE2));

>>    }});

>>

>>    Object actualValue1 = cache.lookup("key1");

>>    Object actualValue2 = cache.lookup("key2");

>>    context.assertIsSatisfied();

>>    assertEquals("lookup with key1", VALUE1, actualValue1);

>>    assertEquals("lookup with key2", VALUE2, actualValue2);

>>    }

>>

>>    public void testLoadsObjectThatIsNotCachedWithMockito() {

>>    Clock clock = mock(Clock.class);

>>    ObjectLoader loader = mock(ObjectLoader.class, "loader");

>>    ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);

>>    TimedCache cache = new TimedCache(loader, clock,

reloadPolicy);

>>

>>    when(clock.time()).thenReturn(loadTime);

>>    when(loader.load(eq("key1"))).thenReturn(VALUE1);

>>    when(loader.load(eq("key2"))).thenReturn(VALUE2);

>>

>>    Object actualValue1 = cache.lookup("key1");

>>    Object actualValue2 = cache.lookup("key2");

>>    verify(loader).load("key1");

>>    verify(loader).load("key2");

>>    verifyNoMoreInteractions(loader);

>>    assertEquals("lookup with key1", VALUE1, actualValue1);

>>    assertEquals("lookup with key2", VALUE2, actualValue2);

>>    }

>>

>> - Neil

>>

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-26T00:05:14Z

They look not too different apart from Mockito makes you duplicate
expectations a bit.

An interesting comparison might be a test that uses jMock's States
mechanism to control ordering and vary the behaviour of mocked calls.

--Nat

On Sunday, October 25, 2009, Neil Swingler <neil@...> wrote:

> I have just given myself a 30 minute crash course in jmock2 by converting one of jmock's very own unit tests to Mockito. OK I only chose the first test but I think it gives a flavour of the differences. The full compiling class is attached but here is the interesting bit. Personally I would probably skip the verify steps in the mockito version but kept them in for completeness.
>
>    public void testLoadsObjectThatIsNotCachedWithJmock() {
>    Mockery context = new Mockery() {{
>    setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
>    }};
>    final Clock clock = context.mock(Clock.class);
>    final ObjectLoader loader = context.mock(ObjectLoader.class, "loader");
>    ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);
>
>    TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
>    context.checking(new Expectations() {{
>    allowing (clock).time(); will(returnValue(loadTime));
>
>    oneOf (loader).load("key1"); will(returnValue(VALUE1));
>    oneOf (loader).load("key2"); will(returnValue(VALUE2));
>    }});
>
>    Object actualValue1 = cache.lookup("key1");
>    Object actualValue2 = cache.lookup("key2");
>    context.assertIsSatisfied();
>    assertEquals("lookup with key1", VALUE1, actualValue1);
>    assertEquals("lookup with key2", VALUE2, actualValue2);
>    }
>
>    public void testLoadsObjectThatIsNotCachedWithMockito() {
>    Clock clock = mock(Clock.class);
>    ObjectLoader loader = mock(ObjectLoader.class, "loader");
>    ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
>    TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
>
>    when(clock.time()).thenReturn(loadTime);
>    when(loader.load(eq("key1"))).thenReturn(VALUE1);
>    when(loader.load(eq("key2"))).thenReturn(VALUE2);
>
>    Object actualValue1 = cache.lookup("key1");
>    Object actualValue2 = cache.lookup("key2");
>    verify(loader).load("key1");
>    verify(loader).load("key2");
>    verifyNoMoreInteractions(loader);
>    assertEquals("lookup with key1", VALUE1, actualValue1);
>    assertEquals("lookup with key2", VALUE2, actualValue2);
>    }
>
> - Neil
>

--
http://www.natpryce.com

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-25T15:56:17Z

I have just given myself a 30 minute crash course in jmock2 by
converting one of jmock's very own unit tests to Mockito. OK I only
chose the first test but I think it gives a flavour of the differences.
The full compiling class is attached but here is the interesting bit.
Personally I would probably skip the verify steps in the mockito version
but kept them in for completeness.

public void testLoadsObjectThatIsNotCachedWithJmock() {
Mockery context = new Mockery() {{
setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
}};
final Clock clock = context.mock(Clock.class);
final ObjectLoader loader = context.mock(ObjectLoader.class,
"loader");
ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
context.checking(new Expectations() {{
allowing (clock).time(); will(returnValue(loadTime));

oneOf (loader).load("key1"); will(returnValue(VALUE1));
oneOf (loader).load("key2"); will(returnValue(VALUE2));
}});

Object actualValue1 = cache.lookup("key1");
Object actualValue2 = cache.lookup("key2");

context.assertIsSatisfied();
assertEquals("lookup with key1", VALUE1, actualValue1);
assertEquals("lookup with key2", VALUE2, actualValue2);
}

public void testLoadsObjectThatIsNotCachedWithMockito() {
Clock clock = mock(Clock.class);
ObjectLoader loader = mock(ObjectLoader.class, "loader");
ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
TimedCache cache = new TimedCache(loader, clock, reloadPolicy);

when(clock.time()).thenReturn(loadTime);
when(loader.load(eq("key1"))).thenReturn(VALUE1);
when(loader.load(eq("key2"))).thenReturn(VALUE2);

Object actualValue1 = cache.lookup("key1");
Object actualValue2 = cache.lookup("key2");

verify(loader).load("key1");
verify(loader).load("key2");

verifyNoMoreInteractions(loader);
assertEquals("lookup with key1", VALUE1, actualValue1);
assertEquals("lookup with key2", VALUE2, actualValue2);
}

- Neil

/* Copyright (c) 2000-2004 jMock.org
*/
package org.jmock.example.timedcache;

import static org.mockito.Matchers.eq;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
import static org.mockito.Mockito.when;

import java.util.Calendar;
import java.util.Date;

import junit.framework.TestCase;

import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit3.JUnit3ErrorTranslator;

public class TimedCacheTests extends TestCase {
private Date loadTime = time(1);
final Object VALUE1 = "value1";
final Object VALUE2 = "value2";

public void testLoadsObjectThatIsNotCachedWithJmock() {
Mockery context = new Mockery() {{
setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
}};
final Clock clock = context.mock(Clock.class);
final ObjectLoader loader = context.mock(ObjectLoader.class, "loader");
ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
context.checking(new Expectations() {{
allowing (clock).time(); will(returnValue(loadTime));

oneOf (loader).load("key1"); will(returnValue(VALUE1));
oneOf (loader).load("key2"); will(returnValue(VALUE2));
}});

Object actualValue1 = cache.lookup("key1");
Object actualValue2 = cache.lookup("key2");

context.assertIsSatisfied();
assertEquals("lookup with key1", VALUE1, actualValue1);
assertEquals("lookup with key2", VALUE2, actualValue2);
}

public void testLoadsObjectThatIsNotCachedWithMockito() {
Clock clock = mock(Clock.class);
ObjectLoader loader = mock(ObjectLoader.class, "loader");
ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
TimedCache cache = new TimedCache(loader, clock, reloadPolicy);

when(clock.time()).thenReturn(loadTime);
when(loader.load(eq("key1"))).thenReturn(VALUE1);
when(loader.load(eq("key2"))).thenReturn(VALUE2);

Object actualValue1 = cache.lookup("key1");
Object actualValue2 = cache.lookup("key2");

verify(loader).load("key1");
verify(loader).load("key2");

verifyNoMoreInteractions(loader);
assertEquals("lookup with key1", VALUE1, actualValue1);
assertEquals("lookup with key2", VALUE2, actualValue2);
}

private Date time(int i) {
Calendar calendar = Calendar.getInstance();
calendar.clear();
calendar.set(Calendar.DAY_OF_YEAR, i);
return calendar.getTime();
}
}

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-25T14:03:47Z

> I agree Nat. I'm just trying to counter the opinion that mockito
> will hide a bad design.

I would love to see if using mockito/jmock actually has any effect on
design. So far, I've peeked into as many as 3 codebases that use
mockito and not been hugely impressed with 2 of them (no, I don't have
any data for jmock).

It would be neat, for example, to run Keith's measure on different
projects and see if there's a significant difference.

S.

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-25T13:01:17Z

2009/10/25 "Günther, Rene - Innflow AG" <rene.guenther@...>:
> Thats interesting. Normally that applies to our objects as well (one or two
> mocks). But our main object (a financial document) has references to almost
> all other objects. The documentManager is interacting with 10-15 other
> managers (to be mocked). Would you recommend to split that manager? Maybe
> you know of some pattern which would help simplify that manager?

I'd consider the fact that it has 10 to 15 dependencies a smell. Also
a smell is the fact that it has a vague word like "manager" in its
name. I'd try to look at what its responsibilities are and divide it
up into objects that perform those responsibilities and are have more
evocative / concrete names.

Exactly what patterns I'd use I cannot say without knowing about the
system and domain.

--Nat

--
http://www.natpryce.com

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

http://xircles.codehaus.org/manage_email

AW: Differences between jMock & Mockito

2009-10-25T11:10:56Z

Thats interesting. Normally that applies to our objects as well (one or two
mocks). But our main object (a financial document) has references to almost
all other objects. The documentManager is interacting with 10-15 other
managers (to be mocked). Would you recommend to split that manager? Maybe
you know of some pattern which would help simplify that manager?

Thanks
Rene

-----Ursprüngliche Nachricht-----
Von: Nat Pryce [mailto:nat.pryce@...]
Gesendet: Sonntag, 25. Oktober 2009 15:01
An: user@...
Betreff: Re: [jmock-user] Differences between jMock & Mockito

2009/10/24 Neil Swingler <neil@...>:
> setting up a lot of mocks is still a pain whichever framework you use.

Our opinion (and jMock is 'opinionated software') is that is your
tests telling you that your object under test has too many
dependencies. A test shouldn't create more than a handful of mocks.
Most tests I see create one or two.

--Nat

--
http://www.natpryce.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

Re: Differences between jMock & Mockito

2009-10-25T09:19:39Z

Mockito won't hide that, I agree.

But it will hide complex inter-object protocols by, for example,
hiding that there are lots of get-calls between objects.

--Nat

2009/10/25 Neil Swingler <neil@...>:

> I agree Nat. I'm just trying to counter the opinion that mockito will hide a
> bad design.
>
> - Neil
>
> On 25 Oct 2009, at 15:00, Nat Pryce <nat.pryce@...> wrote:
>
>> 2009/10/24 Neil Swingler <neil@...>:
>>>
>>> setting up a lot of mocks is still a pain whichever framework you use.
>>
>> Our opinion (and jMock is 'opinionated software') is that is your
>> tests telling you that your object under test has too many
>> dependencies. A test shouldn't create more than a handful of mocks.
>> Most tests I see create one or two.
>>
>> --Nat
>>
>> --
>> http://www.natpryce.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
>
>
>

--
http://www.natpryce.com

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

http://xircles.codehaus.org/manage_email

Re: Differences between jMock & Mockito

2009-10-25T07:13:06Z

I agree Nat. I'm just trying to counter the opinion that mockito will
hide a bad design.

- Neil

On 25 Oct 2009, at 15:00, Nat Pryce <nat.pryce@...> wrote:

> 2009/10/24 Neil Swingler <neil@...>:
>> setting up a lot of mocks is still a pain whichever framework you
>> use.
>
> Our opinion (and jMock is 'opinionated software') is that is your
> tests telling you that your object under test has too many
> dependencies. A test shouldn't create more than a handful of mocks.
> Most tests I see create one or two.
>
> --Nat
>
> --
> http://www.natpryce.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

Re: Differences between jMock & Mockito

2009-10-25T07:00:55Z

2009/10/24 Neil Swingler <neil@...>:
> setting up a lot of mocks is still a pain whichever framework you use.

Our opinion (and jMock is 'opinionated software') is that is your
tests telling you that your object under test has too many
dependencies. A test shouldn't create more than a handful of mocks.
Most tests I see create one or two.

--Nat

--
http://www.natpryce.com

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

http://xircles.codehaus.org/manage_email