Thoughts on jMock and multithreading?

[Nat Pryce]

There's some debate going on among the jMock developers and the users
they know about whether jMock should support testing multithreaded
code.

On one side, at the moment jMock forces you to separate the functional
behaviour of a unit from larger scale concurrency policies, so that
you can test the unit with the DeterministicExecutor or
DeterministicScheduler.

On the other side, lots of Java code is multithreaded and plenty of
people use jMock in multithreaded tests and get wierd errors as a
result.

So... if jMock supported testing multithreaded code, would people find
that a useful feature?  Or probably not use it?

--Nat

--
http://www.natpryce.com

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

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

I'm a bit undecided on this one. So far, we've had a very opinionated  
story, which is that JMock doesn't do multithreading. If you want to  
test threaded code, then there are other ways to do that, especially  
now that Hamcrest is shaping up.

One of our strong claims is that jmock will help you write the "right"  
kind of code because it pushes you into the appropriate corners, for  
example that threaded code should minimise its synchronisation points.  
I fear that we'll lose the message if we make it too easy -- that's  
why mocking classes is an extension and not built-in.

An alternative to implementing support for threads is to complain when  
they're found, which would solve the confusing failures problem.

S.

On 28 Feb 2009, at 17:13, Nat Pryce wrote:

> There's some debate going on among the jMock developers and the users
> they know about whether jMock should support testing multithreaded
> code.
>
> On one side, at the moment jMock forces you to separate the functional
> behaviour of a unit from larger scale concurrency policies, so that
> you can test the unit with the DeterministicExecutor or
> DeterministicScheduler.
>
> On the other side, lots of Java code is multithreaded and plenty of
> people use jMock in multithreaded tests and get wierd errors as a
> result.
>
> So... if jMock supported testing multithreaded code, would people find
> that a useful feature?  Or probably not use it?
>
> --Nat

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
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

[Nat Pryce]

2009/3/1 Steve Freeman <steve@...>:

> I'm a bit undecided on this one. So far, we've had a very opinionated story,
> which is that JMock doesn't do multithreading. If you want to test threaded
> code, then there are other ways to do that, especially now that Hamcrest is
> shaping up.
>
> One of our strong claims is that jmock will help you write the "right" kind
> of code because it pushes you into the appropriate corners, for example that
> threaded code should minimise its synchronisation points. I fear that we'll
> lose the message if we make it too easy -- that's why mocking classes is an
> extension and not built-in.
>
> An alternative to implementing support for threads is to complain when
> they're found, which would solve the confusing failures problem.

The default will be to complain if used from multiple threads, to
nudge design towards a clear separation of logic from concurrency
policy.

However, you still need to test multithreaded code:

1) Even when you separate logic and concurrency policy, you need to
stress-test synchronisation.  JMock can help here by isolating
synchronisation points to pinpoint failures.

2) When you implement an abstraction in terms of third-party code that
calls into your object from multiple threads you may need to use mocks
to test outgoing calls from your object.

--Nat

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

    http://xircles.codehaus.org/manage_email

[MS21]

Hi,
 We are looking for Unit testing strategy for weblogic Workmanager code which uses threads.
Could you pls provide some inputs for this. Whether jMock can be used here or not?


Thanks,

[andrew.j.macgilvery]

Hi Subramanian,
        jMock is suited to testing threaded code.

See http://www.natpryce.com/index.html and http://www.jmock.org/threads.html.

Cheers,
        Andy

"MS21" <subramanian.meena@...>

07-Oct-2009 09:54

Please respond to user@...

       

To	user@...
cc
Subject	Re: [jmock-user] Thoughts on jMock and multithreading?

Hi,
We are looking for Unit testing strategy for weblogic Workmanager code
which uses threads.
Could you pls provide some inputs for this. Whether jMock can be used here
or not?


Thanks,













--
View this message in context: http://www.nabble.com/Thoughts-on-jMock-and-multithreading--tp22264297p25782898.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

-----------------------------------------------------------
This e-mail was sent by GlaxoSmithKline Services Unlimited 
(registered in England and Wales No. 1047315), which is a 
member of the GlaxoSmithKline group of companies. The 
registered address of GlaxoSmithKline Services Unlimited 
is 980 Great West Road, Brentford, Middlesex TW8 9GS.
-----------------------------------------------------------

[Steve Freeman-2]

jMock can work with multithreaded code.

S.

On 7 Oct 2009, at 09:54, MS21 wrote:
> Hi,
> We are looking for Unit testing strategy for weblogic Workmanager code
> which uses threads.
> Could you pls provide some inputs for this. Whether jMock can be  
> used here
> or not?
>

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
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

[Stephen Smith-2]

Nat/Steve

Thanks for sharing your thoughts on the direction of JMock. On multi-threading
support, do you have a specific example in mind where the current API is deemed
inadequate and/or cumbersome?

Steve

Nat Pryce wrote:

> 2009/3/1 Steve Freeman <steve@...>:
>> I'm a bit undecided on this one. So far, we've had a very opinionated story,
>> which is that JMock doesn't do multithreading. If you want to test threaded
>> code, then there are other ways to do that, especially now that Hamcrest is
>> shaping up.
>>
>> One of our strong claims is that jmock will help you write the "right" kind
>> of code because it pushes you into the appropriate corners, for example that
>> threaded code should minimise its synchronisation points. I fear that we'll
>> lose the message if we make it too easy -- that's why mocking classes is an
>> extension and not built-in.
>>
>> An alternative to implementing support for threads is to complain when
>> they're found, which would solve the confusing failures problem.
>
> The default will be to complain if used from multiple threads, to
> nudge design towards a clear separation of logic from concurrency
> policy.
>
> However, you still need to test multithreaded code:
>
> 1) Even when you separate logic and concurrency policy, you need to
> stress-test synchronisation.  JMock can help here by isolating
> synchronisation points to pinpoint failures.
>
> 2) When you implement an abstraction in terms of third-party code that
> calls into your object from multiple threads you may need to use mocks
> to test outgoing calls from your object.
>
> --Nat
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00
>

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

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

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

The API in the current release candidate is close to finalised. I
can't forsee any major changes.

I guess the important question is where do *you* (jmock users) find
inadequate or cumbersome. Speak now or forever hold your peace!

--Nat

On Friday, October 9, 2009, Stephen Smith <steve@...> wrote:

> Nat/Steve
>
> Thanks for sharing your thoughts on the direction of JMock. On multi-threading support, do you have a specific example in mind where the current API is deemed inadequate and/or cumbersome?
>
> Steve
>
> Nat Pryce wrote:
>
> 2009/3/1 Steve Freeman <steve@...>:
>
> I'm a bit undecided on this one. So far, we've had a very opinionated story,
> which is that JMock doesn't do multithreading. If you want to test threaded
> code, then there are other ways to do that, especially now that Hamcrest is
> shaping up.
>
> One of our strong claims is that jmock will help you write the "right" kind
> of code because it pushes you into the appropriate corners, for example that
> threaded code should minimise its synchronisation points. I fear that we'll
> lose the message if we make it too easy -- that's why mocking classes is an
> extension and not built-in.
>
> An alternative to implementing support for threads is to complain when
> they're found, which would solve the confusing failures problem.
>
>
> The default will be to complain if used from multiple threads, to
> nudge design towards a clear separation of logic from concurrency
> policy.
>
> However, you still need to test multithreaded code:
>
> 1) Even when you separate logic and concurrency policy, you need to
> stress-test synchronisation.  JMock can help here by isolating
> synchronisation points to pinpoint failures.
>
> 2) When you implement an abstraction in terms of third-party code that
> calls into your object from multiple threads you may need to use mocks
> to test outgoing calls from your object.
>
> --Nat
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00
>
>
>
> --
> Stephen Smith
> http://www.stephen-smith.co.uk/
>
> ---------------------------------------------------------------------
> 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

[Julian Hall-2]

Nat Pryce wrote:
> The API in the current release candidate is close to finalised. I
> can't forsee any major changes.
>
> I guess the important question is where do *you* (jmock users) find
> inadequate or cumbersome. Speak now or forever hold your peace!
>  
One thing that bugs me.  Consider the following test:

@RunWith (JMock.class)
...

    @Test
    public void mockingOtherThreads () throws Exception
    {
        final TestInterface mock = mockery.mock (TestInterface.class);
        mockery.checking (new Expectations () {
            {
                one (mock).method ();
            }
        });

        Thread t = new Thread () {
            @Override
            public void run ()
            {
                mock.method ();
                mock.otherMethod ();
            }
        };
        t.start ();
        t.join ();
    }


This test passes, despite the fact that the call to mock.otherMethod()
is unexpected.  The test correctly catches the case where mock.method()
is not called, but fails to detect inappropriate calls: a
java.lang.AssertionError is thrown, but nothing is in place to catch
it.  Ideally, I think this assertion error should be stored, and then
rethrown by mockery.assertIsSatisfied().

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

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

You're not using the thread-support classes in the new release
candidate.  You need to create a Synchroniser and set it as the
threading policy of the Mockery.

On Saturday, October 10, 2009, Julian Hall <jules@...> wrote:

> Nat Pryce wrote:
>
> The API in the current release candidate is close to finalised. I
> can't forsee any major changes.
>
> I guess the important question is where do *you* (jmock users) find
> inadequate or cumbersome. Speak now or forever hold your peace!
>
>
> One thing that bugs me.  Consider the following test:
>
> @RunWith (JMock.class)
> ...
>
>    @Test
>    public void mockingOtherThreads () throws Exception
>    {
>        final TestInterface mock = mockery.mock (TestInterface.class);
>        mockery.checking (new Expectations () {
>            {
>                one (mock).method ();
>            }
>        });
>
>        Thread t = new Thread () {
>            @Override
>            public void run ()
>            {
>                mock.method ();
>                mock.otherMethod ();
>            }
>        };
>        t.start ();
>        t.join ();
>    }
>
>
> This test passes, despite the fact that the call to mock.otherMethod() is unexpected.  The test correctly catches the case where mock.method() is not called, but fails to detect inappropriate calls: a java.lang.AssertionError is thrown, but nothing is in place to catch it.  Ideally, I think this assertion error should be stored, and then rethrown by mockery.assertIsSatisfied().
>
> ---------------------------------------------------------------------
> 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