Test Driven Design - where did I go wrong?

Question

I am playing with a toy project at home to better understand Test Driven Design. At first things seemed to be going well and I got into the swing of failing tests, code, passing test.

I then came to add a test and realised it would be difficult with my current structure and that furthermore I should split a particular class which had too many responsibilities. Adding even more responsibilities for the next test was clearly wrong. I decided to put aside this test, and refactor what I had. This is where things started to go wrong.

It was difficult to refactor without breaking lots of tests at once, and then the only option seemed to be to make many changes and hope I ended up back at something where the tests passed again. The tests themselves were valid, I just had to break nearly all of them while refactoring. The refactoring (which I'm still not that happy with) took me five or six hours before I had returned to all tests passing. The tests did help me along the way.

It feels like I got off the TDD track. What do you think I did wrong?

As this is mostly a learning exercise I'm considering rolling back all that refactoring and trying to move forward again in a better fashion.

Answer 1

Perhaps you went too fast when splitting your class. The steps for the Extract Class Refactoring are as follows:

• create the new class
• have an instance of that class as a private data member
• move field to the new class, one by one
• compile and test for each field
• move method to the new class, one by one, testing for each

That way you won't break a large number of tests while refactoring your class, and you can rely on the tests to make sure nothing was broken so far all along the class splitting.

Also, make sure you're testing the behavior, not the implementation.

Answer 2

I wanted to comment the accepted answer but my current reputation does not allow me. So here it is as a new answer.

TDD says:

Create a test that fails. Code a little. Make the test pass.

It insists on coding in tiny steps (especially when beginning). View TDD as systematic validation of successive refactorings you perform to build your programs. If you take too big a step, your refactoring will get out of control.