At what point in the TDD process should I mock?

Question

Just to get any confusion out of the way: I'm starting from the position where I already know what to mock, where and how to do it. I just don't know how to fit the mocking into the TDD process.

So let's say I have a my_function() already done and I want to write MyClass() that uses my_function() somewhere. Let's say my end goal is something like this:

class MyClass():
    (...)
    def some_method():
        var = my_function()
        self._do_something(var)

Writing this the classical way would be easy:

1. Write the code.
2. Realize that my_function() needs to be mocked because it does some connections and stuff.
3. Write a my_function mock.
4. Write a test for MyClass().some_method() using the mock.
5. Run the test.

I want to do it test first though, but so far I've only came up with this:

1. Write the test for MyClass().some_method(), ignoring the mock.
2. Run the test - it fails.
3. Write the code.
4. Run the test - it fails because my_function() has some external dependencies and needs a certain environment etc.
5. Write the mock and change the test.
6. Run the test - it passes.

This approach seems flawed though. I write the test first so I can just run it again and again while writing code, waiting for it to go green. With my approach my test will never go green before I decide that I'm "done" with the code and only then start mocking (because I won't know what to mock before writing the code). Also I'm actually changing the test so it uses the mock, while the code is already "done" so I'm running the test to actually check whether I'm done changing the test, and not changing the code (I hope I'm making sense here).

What do you make of it? Is my TDD process flawed or is it ok and my reasoning about it is flawed? I tried searching the net but I haven't found anyone discussing or explaining this particular aspect. Either it's just mocking, assuming the code is already written, or it's TDD and the assumption is that you don't have any dependencies to mock.

Answer 1

Of course you can't mock the dependency before you realize there's a dependency so in this regard what you are doing is fine. But you might ask yourself why it took you a test failing after writing the code to notice the dependency and what you could do about it.

You didn't notice the dependency because it was not explicit, you only discovered it when you ran the test. Conventional TDD wisdom says that at this point you should reconsider your design to make the dependency explicit, they call it dependency injection. Common ways to do it are passing my_function as an argument to MyClass.some_method or MyClass.__init__.

By using dependency injection you make tests easier to write and read:

1. You missed the dependency because it was not obvious. Making it explicit makes it easier to take into account all needed dependencies when you are writing the test.

2. You were mocking an implementation detail of MyClass.some_method. That could confuse other people reading your test, they would have to look at the implementation code to understand why you are creating an object that the test doesn't use. Dependency injection makes it easier to understand because the object is passed to a method call in the test.

Answer 2

Given that my_function "does connections and stuff", I guess it does so for a reason, which you verify in your test. So the moment you write an assert statement to verify the outcome, you probably already realize the code will need to make connections in order to make the test pass. If you do, it's OK to introduce the mock at that point.

If you don't realize it at that moment, you'll do at step 3 when you write the code. At that point you should only have to change the setup code of your test (to inject the mock and make it return an appropriate response for the call being done during the test). You shouldn't have to change the actual test itself.

In some cases returning an appropriate response (or doing whatever it takes to produce an outcome that can be verified) proves too difficult, and you'd rather just verify that the function has been called with correct arguments. In that case you can choose to deviate from the regular technique. It's all about trade-offs.

Answer 3

A key feature of a "UnitTest" is that is verifies the behavior of the tested unit in isolation.

Therefore you do not decide if mocking is needed by the complexity of my_function() but if it belongs to the same unit.

According to Roy Osherove (The Art Of UnitTesting) it belongs to the same unit if it has the same reason to change.

Because my_function() already exists (having its own set of unittests) it most likey has different reasons to change and (in consequence) is or belongs to a different unit.

Because it is/belongs to a different unit it must be mocked for the current test.

I'm asking "at which point in the TDD process should I actually write the mock and why". – iknownothing

You write the mock when creating the test as soon as you realize that communicating with a dependency (my_function()) is part of the desired behavior of the current unit. And the reason is to keep the current units behavior isolated for the test.

Answer 4

I write the Assert part of my tests first, and never had any problems figuring out when to introduce mocks (or stubs), because it is a logical follow-up to what you're asserting on. Introducing fake objects usually comes up in the early stages of the Red phase.

• In mock-based tests, you know you have to verify stuff recorded by the mock because what matters is that the external dependency it stands for was called correctly. So you write your Asserts first thing and jump to the Arrange part immediately after, to declare the mocks you just verified in the Assert part. Then you instantiate your class under test, somehow injecting it with the mocks, and complete the Act section.

  From there, everything compiles but the test is still red. Then you go on to write the production code that will make it pass.

• Stubs, in contrast, are here to provide canned inputs. In tests that use them, something in the Asserts is usually linked to a value given by the stub. For instance you can stub out a Repository to return an arbitrary object A. In all likelihood, something in your assertions will be related to object A, otherwise you wouldn't bother setting up a stub returning it. Writing the assertions will lead you to using object A and thus force you to write the stub that returns it if you want the test to compile.

• If a new dependency appears as a result of refactoring a class, the original test for the class should still work and cover everything you need. You can refactor your test to fake out the dependency and introduce another test dedicated to the new class if you want, though it is not an obligation - so that would be another legit time to introduce a mock, I guess.