|We don't bite newbies here... much
Testing: To Mock or Not to Mock?by agianni (Hermit)
|on Nov 08, 2007 at 15:15 UTC
agianni has asked for the wisdom of the Perl Monks concerning the following question:
I'm working with some co-workers to develop some best practices for unit test writing and we've run into at least one conflict over what that best practice should be. While there are a number of unresolved questions, the most contentious question was of the degree of isolation that is appropriate in tests. I am generally of the school of thought that isolation is always disable, so I make a lot of use of Test::MockModule and Test::MockObject.
Here's a simple example of some code I might write and the test I would write for it:
I find this useful because I don't have to care about what bar and baz actually do, especially if there is a lot of indirection involved in their implementation; i.e. I don't want to have to dig through three or four (or seven) layers of methods to figure out what to expect for the test.
However, there is a contingent at the office that thinks that setting up the object as implemented is a better option when reasonable. For example, if this was a CGI script and the foo, bar and baz methods were looking at CGI params to determine their return values, I would actually set those CGI params rather than mocking up the methods. The argument here is that this method provides at least a modicum of integration testing between the methods and is likely to uncover errors introduced by interface changes, intentional or otherwise.
What do y'all think? If isolation is generally desirable, are there other kinds of tests that we can use to try to catch other kinds of errors? We do a limited amount of testing with WWW::Mechnize. We actually do less than we used to since we've started taking unit test coverage more seriously and we have no standard as to what we test with mech tests.