Before I learnt TDD if I had a problem with my code the only way I could really find out more about that problem was to turn to the debugger.

One of the aims of writing code test first is to remove the need to debug. As Pat Kua points out in his blog, when you use a TDD approach to writing code, a nice side effect is that you tend to stop using the debugger so much.

Doing TDD is not enough though, we want to look to design our tests for failure so that they do fail we have a useful error message that helps us work out why something failed rather than having to get out the debugger to work it out. Hamcrest matchers are really useful for this, particularly when it comes to analysing test case failures from a continuous integration tool’s console.

Writing our tests in a consistent style also helps especially when it comes to setting up mocks and stubs from my experience. If we know how and where these have been setup then we don’t need to resort to the debugger to work out why one was or wasn’t called - it should be obvious just from reading the test.

This is an idea which I touched on in a post I wrote around how writing clean OO code can help reduce the cost of change in our applications, the suffering that having too much mutable state can cause you becoming abundantly clear to me after a coding dojo session where we did just that.

Even using the debugger was difficult because we were trying to remember what the state was meant to be compared to how it actually was.

Greg Young has an interesting presentation which he gave at a Europe Virtual Alt.NET meeting in February (there is also a similar interview on InfoQ) where he talks about how we can model state transitions explicitly by using command objects rather than implicitly by having domain objects keep track of a lot of internal state.

He also describes the use of getters/setters as a domain anti-pattern which I would certainly agree with as it results in behaviour being defined away from the data, usually resulting in unexpected state changes in our objects which we can’t figure out without getting out the debugger.

Ensuring that our classes don’t have too many dependencies is another useful approach - an anti-pattern which tends to happen quite frequently in the controller of the MVC pattern.

When too much is happening in classes they become difficult to understand and by virtue difficult to test, resulting in increased debugger usage because we’ve probably missed out some paths through the code inadvertently.

When this happens we want to try and pull some of the similar operations out into another controller to make our life easier.

These are some of the ways that I have noticed help reduce our need to rely on the debugger.

Using TDD as an approach to coding helped me cut down my debugger usage a lot and it is no longer my first choice of tool when there is a problem with code.

I’m sure there are other ways to reduce the need to debug, I just haven’t discovered them yet!