RHQ & mockito

John Mazzitelli jmazzite at redhat.com
Mon Feb 6 13:12:34 UTC 2012


> 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 :)




More information about the rhq-devel mailing list