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.