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 were testing a too low a level. It's hard to say without seeing you code, but typically I test a feature from end to end, and make sure all the behaviour I expected to happen, happened. Testing every single method in isolation will give you the test-web you have created.

You can use tools like NCover and DotCover to check that you haven't missed any code paths.

Answer 2

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 3

The only thing "wrong" was to add a test afterwards. In "true" TTD you first declare all tests before the actual implementation. I say "true" because that's often only theory. But in practice you still have the safty given by the tests.

Answer 4

This is, sadly, something TDD proponents don't talk about enough and that makes people try TDD and then abandon it.

What I do is what I call "High Level Testing" which consists in avoiding unit tests and doing exclusively high level tests (which we could could call "integration tests"). It works pretty well and I avoid the (very important) problem you mentioned. I wrote an article about it a while ago:

http://www.hardcoded.net/articles/high-level-testing.htm

Good luck with TDD, don't give up yet.

Answer 5

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.

Answer 6

Also for TDD continuos regression of test cases are also necessary. So Continuos integration with Coverage tools(as mentioned above) are necessary. So that small changes(i.e Refactoring) can be regressed easily and whether any code path which are missed can be found easily.

Also I feel that if tests were not written previously, time should not be wasted to think whether to write tests or not. Tests should be written immediately.