Note: the code referenced in this post, along with some extra context, can be found on github. I have tried to link into the repo at each of the inline code samples, for convenience. It might be useful to refer to the repo as a whole, though, rather than just the swatches under discussion.
When I write unit tests, I often use mock objects to help me isolate the code I’m testing. I usually use Michael Foord’s mock library to make mocking out dependencies easy. For many test applications, it’s got exactly what I need. Sometimes, though, I need something a little more.
This Calls for a Little Mockery!
Mock provides a variety of efficient ways to make use of mock objects. Most of the introductory material I have read recommends using patch as a decorator, and indicates that you can also use it as a context manager if you wish. This leads to unit tests that look something like this:
class MeanTest(unittest.TestCase): @patch('summaries.SeriesManager') def test_01_empty_series(self, sm): self.get_series = gs = sm.get_series gs.return_value =  retval = summaries.mean_for_series('foofah') self.assertEqual(retval, 0) self.get_series.assert_called_once()
This works great on a small scale, and you could build whole unit test suites with no more technology than this.
DRY Mockery is Best
The example code is simple enough that it wouldn’t crush your soul if you opened a file and saw twenty-five unit tests just like it. But even in those scant five lines, at least two of them are repeated: we only need to set get_series one time, and most of our unit tests are going to provide a return value for get_series. We might try to refactor like so:
class RevisedMeanTest(unittest.TestCase): def _set_up_mock(self, series_mgr, series): self.get_series = series_mgr.get_series self.get_series.return_value = series @patch('summaries.SeriesManager') def test_01_empty_series(self, sm): self._set_up_series_mgr(sm, ) retval = summaries.mean_for_series('foofah') self.assertEqual(retval, 0) self.get_series.assert_called_once()
This also works just fine, but it’s not quite optimal. Each test still gets decorated with the patch call. If your test suite installs more than one mock object via patch, this can get extremely cumbersome — I have worked with some test suites that have patched in five or six mock objects. The stack of decorators can take up more lines than the actual test body!
The False Promises of setUp
The beauty of the decorator solution is that it applies the patch before your test runs, and then it removes the patch when the test has concluded. The problem with the decorator approach is mainly that we copy/paste a big stack of decorators onto each method, and that the decorator does not permit us to set up our mocks properly.
The unittest library has a setUp and tearDown feature that seems to fit what we’re after. We can apply the patch in the setUp, and remove the patch in the tearDown. We can also do extra setup work in the setUp method, factoring that extra code out of the test methods.
In practice it’s not quite as elegant as it sounds. Firstly, it’s a little complicated to use these methods. Replicating the work the decorator does takes a few lines of code:
class SettingUpAMeanTest(unittest.TestCase): """ Using setUp and tearDown to set up mocks """ def setUp(self): self.get_series = m = Mock(return_>Introducing PatchingTestCase</h2> We’re almost refactored, but before we get there, I’d like to scroll back a little ways. When we moved the patching into setUp, we traded a one-line decorator call in for three lines of patch setup and teardown. That’s not a terrible amount of overhead, but it lends itself quite well to abstraction. The code to abstract it is in the PatchingTestCase class: class PatchingTestCase(unittest.TestCase): def patch(self, target, attribute, obj=None): if obj is None: obj = mock.Mock() patched = mock.patch.object(target, attribute, obj) obj = patched.start() self.addCleanup(patched.stop) return obj
There’s nothing magical about this code; you could imagine deriving it yourself after a few rounds of writing it as a one off. And in fact, that’s exactly how I came up with it, at least twice now. This patch method works very much like the @patch.object decorator, but in method form. This allows us to apply patches at will, rather than just around functions, or just around blocks.
A Small Concession
We’re left one last problem to solve, which is that not all tests on a given class will necessarily have exactly the same mock setup. In our sample code, the principal difference is in the series data we return. Real-life examples are often substantially more complex. Sometimes, though, you only need the presence of a mock for all your tests to run, and no special behavior. In those cases, setUp will do quite nicely! But for everyone else, read on.
In our campaign to reduce the number of repeated lines of code, we have made significant progress, first centralizing the setup logic, then the decorators, then the patching infrastructure. But now we must give some ground. In order for each test to customize its environment, each test will need to make a method call. Check it out:
def _patch_series_manager(self, series):
self.get_series = m = Mock(return_