The next step after mocking?

[allspiritseve]

I am trying to get myself into a TDD mindset, (it's hard when I'm just programming on and off when I have free time-- not that often at my school) but I have a question about mocks. Or more specifically, what comes after mocking. I get the idea behind mocking a class-- its a good way to discover the interface for the next class you write. However, what happens next? Do you write the class that was mocked, and gradually replace the mock code with calls to the new class? If so, that seems like the first class would be too dependent on the second class, and kind of goes against TDD methodology. If not, what happens when you change the interface of the new class? Are you just supposed to keep mocks up to date as you go along? That sounds like a nightmare.

[Chris Corbyn]

You use the mock when testing the dependent component. Then you write the class which provides the real implementation with it's own set of tests. If your class provides the implementation that your mock demonstrated then everything should just work.

You can provide a separate set of end-to-end tests using both real components if you want to, but certainly do not edit your first tests to remove the mock.

[allspiritseve]

And then what if the interface of the dependent class changes during the course of testing?

[Chris Corbyn]

And then what if the interface of the dependent class changes during the course of testing?

Then yes, you do need to change your mock code. This is a bit of a problem refactoring. Anything which changes an interface will always require code changes both in the production code and in the test code. The trick is to try and minimize the number of places you need to change the code. In your tests use Creation Methods (little factory methods) to set up your object under test and any of it's dependencies (mock or real objects). Mots of the differences will often be in the setup of the object you're testing. If you can delegate that setup to a single method or a few smaller methods then you have a lot less code to change if your interface changes. Anything which minimizes duplication in test code is good in the just the same way avoiding duplication in production code is. You have to maintain your tests just like you have to maintain your production code -- just try to make it as easy as possible to do that.