river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Mock Libs...
Date Thu, 30 Apr 2009 23:34:40 GMT
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.



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 <pdoubleya@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
> 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.

View raw message