You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dan Rollo <da...@gmail.com> on 2009/04/30 03:56:26 UTC

Mock Libs...

I noticed the lines below, which make me think you're using EasyMock.
After using EasyMock for a while, I came across Mockito 
(http://mockito.org). I'm now a Mockito convert - I like how you don't 
have to worry about replay(...) with Mockito, and it had fewer problems 
with an IDE "pre-evaluating" expressions while debugging (which leads to 
very misleading errors from EasyMock). Just wanted to mention it in case 
you hadn't heard of it.

Dan


+		TxnTable mockTxnTable = createNiceMock(TxnTable.class);
+		replay(mockTxnTable);

Re: Mock Libs...

Posted by Peter Firmstone <ji...@zeus.net.au>.
You've a good sense of humor Tom ol' boy.

Your doing the work, I'm happy with whatever you choose, good progress ;)

Cheers,

Peter.



Tom Hobbs wrote:
>> I don't bother setting up specific unit tests for small classes when
>>     
> they
>   
>> end up getting tested indirectly
>>     
>
> Well there's an invitation to start a religious war!  :-)
>
> Seriously though, as you say "horses for courses".
>
> So that's;
>
> +2 for Mockito
> +1 for JMock
> +1 for EasyMock
>
> I'll leave the voting open until I manage to get around to being able to
> commit some more files and see what's winning then.  
>
> Unless there's a more ASF way to decide how long to leave this question
> open before someone takes any action?
>
> Cheers,
>
> Tom
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au] 
> Sent: 01 May 2009 00:35
> To: river-dev@incubator.apache.org
> Subject: Re: Mock Libs...
>
> I've been reading up on Mocking, thanks for the heads up.  To date, when
>
> testing, I create & destroy the necessary objects with setup and tear 
> down, I admit that it does get labourious, sometimes it helps me find 
> errors in other code, I don't bother setting up specific unit tests for 
> small classes when they end up getting tested indirectly.  One might 
> argue that this takes longer to track down the error for a failed test.
>
> Horses for courses I guess.
>
> Checking the result of methods calls etc using unit testing, doesn't 
> confirm however whether there are any deadlocks or problems with 
> synchronisation in the code, JUnit can ignore exceptions. While no one 
> expects testing to find all bugs with code, the good thing about testing
>
> is, it improves one's confidence that code is working properly.  
> Definitely better than not testing at all.
>
> While not experienced enough with, or yet convinced of the benefits of 
> Mocking, after googling and reading others opinions (not using) if I 
> were to choose;
>
> I'd go with Dan's suggestion to use Mockito. ;)
>
> An interesting perspective.
>
> Cheers,
>
> Peter.
>
> Tom Hobbs wrote:
>   
>> As far as I'm concerned, the reason is the standard one for using
>>     
> mocks.
>   
>> There was code that needed to be tested that can only be created/used
>> when it has access to other objects which are not the current test
>> subjects.
>>
>> To isolate the code under test, I created an instance and instead of
>> passing in real objects to its constructor, I passed in mocks.  This
>>     
> has
>   
>> the effect of ensuring that no other business code gets executed
>>     
> during
>   
>> the test run apart from the code currently under test.  
>>
>> Also, with the mocks, we can supply known and predictable behaviour to
>> its method calls which the code under test might be reasonably
>>     
> expected
>   
>> to use.  Obviously, this has the added benefit of preventing any bugs
>>     
> in
>   
>> the supporting code (which is not being tested) from manifesting
>> themselves as bugs in the code under test.
>>
>> Sorry for labouring the point, I'm using this email to answer Peter's
>> "Whats a mocking Tool?" question as well.
>>
>> In my experience of writing unit tests for services, there are so many
>> dependencies that the only way to isolate the code is to make
>>     
> extensive
>   
>> use of mock objects.
>>
>> Hopefully that makes sense.
>>
>> Tom
>>
>> -----Original Message-----
>> From: Jonathan Costers [mailto:jonathan.costers@googlemail.com] 
>> Sent: 30 April 2009 13:45
>> To: river-dev@incubator.apache.org
>> Subject: Re: Mock Libs...
>>
>> Would you be able to explain why we need a Mock objects framework for
>> this?
>>
>> Thanks
>> Jonathan
>>
>> 2009/4/30 Patrick Wright <pd...@gmail.com>
>>
>>   
>>     
>>>> Yes I am (was?) using EasyMock, simply because that's what I'm
>>>>       
>>>>         
>> familiar
>>   
>>     
>>>> with.  I have never heard of Mockito before, but if you say it is
>>>>       
>>>>         
>> better
>>   
>>     
>>>> then again, I'm happy to move over to that.
>>>>
>>>> Does anyone else have any preferences?
>>>>       
>>>>         
>>> At our workplace, we've been using JMock for quite some time and are
>>> very happy with it. We haven't tested the alternatives, not in the
>>> recent past, at least.
>>>
>>>
>>> Regards,
>>> Patrick
>>>
>>>     
>>>       
>> www.sucdenfinancial.com
>>
>> Sucden Financial Limited, Plantation Place South, 60 Great Tower
>>     
> Street, London EC3R 5AZ
>   
>> Telephone +44 203 207 5000
>>
>> Registered in England no. 1095841
>> VAT registration no. GB 446 9061 33
>>
>> Authorised and Regulated by the Financial Services Authority (FSA) and
>>     
> entered in the FSA register under no. 114239
>   
>> This email, including any files transmitted with it, is confidential
>>     
> and may be privileged. It may be read, copied and used only by the
> intended recipient. If you are not the intended recipient of this
> message, please notify postmaster@sucfin.com immediately and delete it
> from your computer system.
>   
>> We believe, but do not warrant, that this email and its attachments
>>     
> are virus-free, but you should check.
>   
>> Sucden Financial Limited may monitor traffic data of both business and
>>     
> personal emails. By replying to this email, you consent to Sucden
> Financial 's monitoring the content of any emails you send to or receive
> from Sucden Financial . Sucden Financial is not liable for any opinions
> expressed by the sender where this is a non-business email.
>   
>> The contents of this e-mail do not constitute advice and should not be
>>     
> regarded as a recommendation to buy, sell or otherwise deal with any
> particular investment.
>   
>> This message has been scanned for viruses by Mimecast.
>>   
>>     
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
>
> This message has been scanned for viruses by Mimecast.
>   


Re: Mock Libs...

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, May 2, 2009 at 3:37 PM, Jukka Zitting <ju...@gmail.com> wrote:

> A vote would only be needed if there were competing code contributions
> based on different libraries and nobody would want to adjust their
> code.

Yes. "He who writes the test uses the testing tools he wants."
Since there is no technical overlap, there is no reason to make it
harder to create tests.

Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

Re: Mock Libs...

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Fri, May 1, 2009 at 1:35 PM, Tom Hobbs <to...@sucfin.com> wrote:
> Unless there's a more ASF way to decide how long to leave this question
> open before someone takes any action?

The ASF way is that whoever starts to write unit tests that require a
mock library gets to choose which library to use (within the bounds of
ASF licensing policy). Input from the dev@ list is certainly welcome
and should be used to guide the decision, but ultimately the decision
is up to the people who actually write the code.

A vote would only be needed if there were competing code contributions
based on different libraries and nobody would want to adjust their
code.

BR,

Jukka Zitting

RE: Mock Libs...

Posted by Tom Hobbs <to...@sucfin.com>.
> I don't bother setting up specific unit tests for small classes when
they
> end up getting tested indirectly

Well there's an invitation to start a religious war!  :-)

Seriously though, as you say "horses for courses".

So that's;

+2 for Mockito
+1 for JMock
+1 for EasyMock

I'll leave the voting open until I manage to get around to being able to
commit some more files and see what's winning then.  

Unless there's a more ASF way to decide how long to leave this question
open before someone takes any action?

Cheers,

Tom

-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au] 
Sent: 01 May 2009 00:35
To: river-dev@incubator.apache.org
Subject: Re: Mock Libs...

I've been reading up on Mocking, thanks for the heads up.  To date, when

testing, I create & destroy the necessary objects with setup and tear 
down, I admit that it does get labourious, sometimes it helps me find 
errors in other code, I don't bother setting up specific unit tests for 
small classes when they end up getting tested indirectly.  One might 
argue that this takes longer to track down the error for a failed test.

Horses for courses I guess.

Checking the result of methods calls etc using unit testing, doesn't 
confirm however whether there are any deadlocks or problems with 
synchronisation in the code, JUnit can ignore exceptions. While no one 
expects testing to find all bugs with code, the good thing about testing

is, it improves one's confidence that code is working properly.  
Definitely better than not testing at all.

While not experienced enough with, or yet convinced of the benefits of 
Mocking, after googling and reading others opinions (not using) if I 
were to choose;

I'd go with Dan's suggestion to use Mockito. ;)

An interesting perspective.

Cheers,

Peter.

Tom Hobbs wrote:
> As far as I'm concerned, the reason is the standard one for using
mocks.
>
>
> There was code that needed to be tested that can only be created/used
> when it has access to other objects which are not the current test
> subjects.
>
> To isolate the code under test, I created an instance and instead of
> passing in real objects to its constructor, I passed in mocks.  This
has
> the effect of ensuring that no other business code gets executed
during
> the test run apart from the code currently under test.  
>
> Also, with the mocks, we can supply known and predictable behaviour to
> its method calls which the code under test might be reasonably
expected
> to use.  Obviously, this has the added benefit of preventing any bugs
in
> the supporting code (which is not being tested) from manifesting
> themselves as bugs in the code under test.
>
> Sorry for labouring the point, I'm using this email to answer Peter's
> "Whats a mocking Tool?" question as well.
>
> In my experience of writing unit tests for services, there are so many
> dependencies that the only way to isolate the code is to make
extensive
> use of mock objects.
>
> Hopefully that makes sense.
>
> Tom
>
> -----Original Message-----
> From: Jonathan Costers [mailto:jonathan.costers@googlemail.com] 
> Sent: 30 April 2009 13:45
> To: river-dev@incubator.apache.org
> Subject: Re: Mock Libs...
>
> Would you be able to explain why we need a Mock objects framework for
> this?
>
> Thanks
> Jonathan
>
> 2009/4/30 Patrick Wright <pd...@gmail.com>
>
>   
>>> Yes I am (was?) using EasyMock, simply because that's what I'm
>>>       
> familiar
>   
>>> with.  I have never heard of Mockito before, but if you say it is
>>>       
> better
>   
>>> then again, I'm happy to move over to that.
>>>
>>> Does anyone else have any preferences?
>>>       
>> At our workplace, we've been using JMock for quite some time and are
>> very happy with it. We haven't tested the alternatives, not in the
>> recent past, at least.
>>
>>
>> Regards,
>> Patrick
>>
>>     
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower
Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and
entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential
and may be privileged. It may be read, copied and used only by the
intended recipient. If you are not the intended recipient of this
message, please notify postmaster@sucfin.com immediately and delete it
from your computer system.
>
> We believe, but do not warrant, that this email and its attachments
are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and
personal emails. By replying to this email, you consent to Sucden
Financial 's monitoring the content of any emails you send to or receive
from Sucden Financial . Sucden Financial is not liable for any opinions
expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be
regarded as a recommendation to buy, sell or otherwise deal with any
particular investment.
>
> This message has been scanned for viruses by Mimecast.
>   

www.sucdenfinancial.com

Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000

Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.

Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.

The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.

This message has been scanned for viruses by Mimecast.

Re: Mock Libs...

Posted by Peter Firmstone <ji...@zeus.net.au>.
I've been reading up on Mocking, thanks for the heads up.  To date, when 
testing, I create & destroy the necessary objects with setup and tear 
down, I admit that it does get labourious, sometimes it helps me find 
errors in other code, I don't bother setting up specific unit tests for 
small classes when they end up getting tested indirectly.  One might 
argue that this takes longer to track down the error for a failed test.  
Horses for courses I guess.

Checking the result of methods calls etc using unit testing, doesn't 
confirm however whether there are any deadlocks or problems with 
synchronisation in the code, JUnit can ignore exceptions. While no one 
expects testing to find all bugs with code, the good thing about testing 
is, it improves one's confidence that code is working properly.  
Definitely better than not testing at all.

While not experienced enough with, or yet convinced of the benefits of 
Mocking, after googling and reading others opinions (not using) if I 
were to choose;

I'd go with Dan's suggestion to use Mockito. ;)

An interesting perspective.

Cheers,

Peter.

Tom Hobbs wrote:
> As far as I'm concerned, the reason is the standard one for using mocks.
>
>
> There was code that needed to be tested that can only be created/used
> when it has access to other objects which are not the current test
> subjects.
>
> To isolate the code under test, I created an instance and instead of
> passing in real objects to its constructor, I passed in mocks.  This has
> the effect of ensuring that no other business code gets executed during
> the test run apart from the code currently under test.  
>
> Also, with the mocks, we can supply known and predictable behaviour to
> its method calls which the code under test might be reasonably expected
> to use.  Obviously, this has the added benefit of preventing any bugs in
> the supporting code (which is not being tested) from manifesting
> themselves as bugs in the code under test.
>
> Sorry for labouring the point, I'm using this email to answer Peter's
> "Whats a mocking Tool?" question as well.
>
> In my experience of writing unit tests for services, there are so many
> dependencies that the only way to isolate the code is to make extensive
> use of mock objects.
>
> Hopefully that makes sense.
>
> Tom
>
> -----Original Message-----
> From: Jonathan Costers [mailto:jonathan.costers@googlemail.com] 
> Sent: 30 April 2009 13:45
> To: river-dev@incubator.apache.org
> Subject: Re: Mock Libs...
>
> Would you be able to explain why we need a Mock objects framework for
> this?
>
> Thanks
> Jonathan
>
> 2009/4/30 Patrick Wright <pd...@gmail.com>
>
>   
>>> Yes I am (was?) using EasyMock, simply because that's what I'm
>>>       
> familiar
>   
>>> with.  I have never heard of Mockito before, but if you say it is
>>>       
> better
>   
>>> then again, I'm happy to move over to that.
>>>
>>> Does anyone else have any preferences?
>>>       
>> At our workplace, we've been using JMock for quite some time and are
>> very happy with it. We haven't tested the alternatives, not in the
>> recent past, at least.
>>
>>
>> Regards,
>> Patrick
>>
>>     
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
>
> This message has been scanned for viruses by Mimecast.
>   


RE: Mock Libs...

Posted by Tom Hobbs <to...@sucfin.com>.
As far as I'm concerned, the reason is the standard one for using mocks.


There was code that needed to be tested that can only be created/used
when it has access to other objects which are not the current test
subjects.

To isolate the code under test, I created an instance and instead of
passing in real objects to its constructor, I passed in mocks.  This has
the effect of ensuring that no other business code gets executed during
the test run apart from the code currently under test.  

Also, with the mocks, we can supply known and predictable behaviour to
its method calls which the code under test might be reasonably expected
to use.  Obviously, this has the added benefit of preventing any bugs in
the supporting code (which is not being tested) from manifesting
themselves as bugs in the code under test.

Sorry for labouring the point, I'm using this email to answer Peter's
"Whats a mocking Tool?" question as well.

In my experience of writing unit tests for services, there are so many
dependencies that the only way to isolate the code is to make extensive
use of mock objects.

Hopefully that makes sense.

Tom

-----Original Message-----
From: Jonathan Costers [mailto:jonathan.costers@googlemail.com] 
Sent: 30 April 2009 13:45
To: river-dev@incubator.apache.org
Subject: Re: Mock Libs...

Would you be able to explain why we need a Mock objects framework for
this?

Thanks
Jonathan

2009/4/30 Patrick Wright <pd...@gmail.com>

> > Yes I am (was?) using EasyMock, simply because that's what I'm
familiar
> > with.  I have never heard of Mockito before, but if you say it is
better
> > then again, I'm happy to move over to that.
> >
> > Does anyone else have any preferences?
>
> At our workplace, we've been using JMock for quite some time and are
> very happy with it. We haven't tested the alternatives, not in the
> recent past, at least.
>
>
> Regards,
> Patrick
>

www.sucdenfinancial.com

Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000

Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.

Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.

The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.

This message has been scanned for viruses by Mimecast.

Re: Mock Libs...

Posted by Jonathan Costers <jo...@googlemail.com>.
Would you be able to explain why we need a Mock objects framework for this?

Thanks
Jonathan

2009/4/30 Patrick Wright <pd...@gmail.com>

> > Yes I am (was?) using EasyMock, simply because that's what I'm familiar
> > with.  I have never heard of Mockito before, but if you say it is better
> > then again, I'm happy to move over to that.
> >
> > Does anyone else have any preferences?
>
> At our workplace, we've been using JMock for quite some time and are
> very happy with it. We haven't tested the alternatives, not in the
> recent past, at least.
>
>
> Regards,
> Patrick
>

Re: Mock Libs...

Posted by Patrick Wright <pd...@gmail.com>.
> Yes I am (was?) using EasyMock, simply because that's what I'm familiar
> with.  I have never heard of Mockito before, but if you say it is better
> then again, I'm happy to move over to that.
>
> Does anyone else have any preferences?

At our workplace, we've been using JMock for quite some time and are
very happy with it. We haven't tested the alternatives, not in the
recent past, at least.


Regards,
Patrick

RE: Mock Libs...

Posted by Tom Hobbs <to...@sucfin.com>.
Hi Dan,

Yes I am (was?) using EasyMock, simply because that's what I'm familiar
with.  I have never heard of Mockito before, but if you say it is better
then again, I'm happy to move over to that.  

Does anyone else have any preferences?

Thanks for the heads up.

Tom

-----Original Message-----
From: Dan Rollo [mailto:danrollo@gmail.com] 
Sent: 30 April 2009 02:56
To: river-dev@incubator.apache.org
Subject: Mock Libs...

I noticed the lines below, which make me think you're using EasyMock.
After using EasyMock for a while, I came across Mockito 
(http://mockito.org). I'm now a Mockito convert - I like how you don't 
have to worry about replay(...) with Mockito, and it had fewer problems 
with an IDE "pre-evaluating" expressions while debugging (which leads to

very misleading errors from EasyMock). Just wanted to mention it in case

you hadn't heard of it.

Dan


+		TxnTable mockTxnTable = createNiceMock(TxnTable.class);
+		replay(mockTxnTable);

www.sucdenfinancial.com

Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000

Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.

Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.

The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.

This message has been scanned for viruses by Mimecast.