RHQ & mockito

Stefan Negrea snegrea at redhat.com
Mon Feb 13 23:22:31 UTC 2012


Hello Mazz,


I totally agree that neither extreme is good (all mocking vs all integration); both methods have a perfect time and place for application. Because RHQ integrates with other products, integration tests usually need configuration/start of external dependencies before execution. This brings us back to the original dilemma: Do we write tests that automatically start dependencies or use mocking to avoid all that? A blend of both would be best ... With mockito & PowerMock we have a strong foundation to do mocking, now we need to develop the infrastructure to control external dependencies.

Folwer's article is an excellent introduction to mocking but the article was written in early 2007 and is a bit dated. There are some concepts that shaped differently in these 5 years; I will just talk about two important ones here. Early frameworks made a clear difference between mocks and stubs, one had to explicitly make a choice when writing tests. The difference between mocks and stubs are nicely presented in Fowler's article. The second difference is rigid mock verification at the end of a test. In EasyMock all the mocks need to have perfect verification. If a method is prescribed to be called three times then calling it twice or four times is a failure. Also everything is verified, no exception. 

mockito is a prime example of advancements in this mocking craziness. First, mockito does not make a difference between mocks and stubs, everything is a stub that can be augmented to behave like a mock (or vice-versa :). Mocked objects return Java defaults unless configured otherwise; there are no errors calling something that is not setup. Reading mockito's older documentation I can see that it took them a few iterations to get this concept correct. Second, the verification of mocks is explicit (no implicit overarching verify all). At the end of a test the developer needs to explicitly verify calls on mock objects. This shifts the design from writing perfect full tests to focusing only on interactions of interest. When I wrote tests for ContentManagerBean my focus was on 10 lines of code I changed. At the end of the test I added verification only for interactions in those 10 lines.

My earlier point about community comes into picture here... These changes & compromises came about because of necessity and getting a better understanding on mocking (and TDD in general). Active communities emerged with lots of design refinements. The concepts are still shifting but so far it just got better with each iteration. All this being said, there is no such thing as perfect mocking framework or even the blueprint for a perfect framework. 


Thank you,
Stefan Negrea





----- Original Message -----
> From: "John Mazzitelli" <jmazzite at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Monday, February 6, 2012 7:12:34 AM
> Subject: Re: RHQ & mockito
> 
> > From a pure unit testing perspective, mocking or stubbing every
> > single dependency is the best approach. That way the
> > object/method under test is completely isolated in a
> > box and all the calls outside that box are controlled
> > and verified by the test.
> 
> This is where I disagree.
> 
> After reading Fowler's "Mocks Aren't Stubs" article:
> 
> http://martinfowler.com/articles/mocksArentStubs.html
> 
> you come to realize this is a common debate - something he calls
> "Classicist vs Mockist".
> 
> I land on the Classicist side of the fence. Even if the mocking
> framework is great, mocking out EVERY object not under test to me
> wastes
> a great opportunity to get much better code coverage.  The mockist
> can
> only get the same amount of test code coverage by spending more time
> writing alot more tests. Like Ian says, if you utilize alot of the
> "real" code (and not mock out everything not under test), then you
> get
> testing coverage EVEN IN parts that aren't actually under the test
> you
> are writing. To me, that's a bonus! Why waste what amounts to a
> "free"
> opportunity to test other parts of the code while testing a different
> part?
> 
> Now, according to Fowlers article, if there is a bug in the "real"
> system being utilized but not under test, your tests might fail in
> parts
> other than that under test and this may be hard to find by just
> debugging your tests. So a failed test might cause you more work
> finding
> out what broke.
> 
> However, this scenario (regardless of how much time it takes to find
> out
> what went wrong - which probably isn't all THAT much anyway) IMO is a
> "good thing". Even though it might not be obvious why or what failed,
> the fact of the matter is you detected erroneous behavior in your
> code
> (even if it wasn't on purpose or on parts you weren't testing - but
> should that matter? Its good you found a bug even if by
> serendipity!).
> 
> Utilizing as much of the "real" code as possible in as many tests as
> possible to me can only enhance the tests' usefulness and can only
> increase test code coverage. IMO :)
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list