I agree, the thing I was trying to warn about is meticulously mocking out everything you possibly can to test every single method/class in complete isolation fr

I agree, the thing I was trying to warn about is meticulously mocking out everything you possibly can to test every single method/class in complete isolation from the rest of the system. It's very tempting to start doing this when you get into heavy unit testing, but I find in practice this adds more cost than value. As an example, lets take some python code I just made up which formats some input into a message, throws the message onto the queue, and returns the message ID. class DelayedJob(object): def __init__(self, queue): self.queue = queue def add_job(self, task, params, priority=1): m = JSONMessage({ task: task, params: params, }) self.queue.add(m, priority) return m.getID() It's pretty clear that the queue service needs to be mocked out, as you don't want to be talking to a real queue for a unit test (you'll probably want some sort of acceptance/integration test to cover this somewhere). However, I have in the past been tempted to make the JSONMessage class injectable, and then inject a mock with a stubbed implementation of getID - I've often seen other people do this as well. The code required to set-up such a fake would be fairly verbose and add little in the way of extra clarity to the test. Since the class is fast and simple (in this scenario it's just a container) then I'd just leave the concrete class in use.