Testing: disciplin, attitude and intuition (1/3)

This is the first of 3 entries that make testing look like a martial art,...

Disciplin

Test-driven development is a really wonderful idea. Start doing it and you'll catch the fever. There are many sources that establish all the benefits of this approach. However, we're still human people,...

I personaly find it difficult to do pure test-driven development when:

• In the process of implementing necessary code to make one test pass, I have to write new code in other classes that should also be tested. Sometimes, I am so much into getting that green bar, that it's not so easy to digress and start fully testing/developing something else
  

• When I develop a new idea, a new implementation across a whole set of classes, I may want to write code that could end up not being the right approach for my current objective. Should I then write the tests for something that may really not function as planned and that should be thrown away?

The "sensible" approach to those 2 questions may be: "no Eric, don't sell your soul to the Devil, you have to test each and every line of code that you produce". So I should:

• Set aside my first testing goal, clarify what I expect of each new operation I am developing and test it, even if it may cause a delay for the first green bar, or for the exploratory design

But I live in reality and I actually find it more rewarding and productive to do what I want to do to a certain extent without testing it first. The trick is,...

...to always have a tasks list for the things that should be tested:

• Once you have the first green bar, go back to the list and test everything that hasn't been tested
• Ditto for the exploratory design

I have exceptions for that process. If I need to develop something that's really not easy along the way, I switch back to the TDD mode, because I simply know that I will produce missing code faster.

"Ok, ok, Eric, it's nice to learn about your fascinating worklife, but what's the point?".

Well, the point is that one: in order to succeed, you need disciplin.

You absolutely need to get back to your list. I found that 2 nice ways to do that:

• Use your buddy! When you practise pair-programming, your partner should always have the responsability for the tasks list. He is your Master that should help you with the disciplin stuff (this also goes for coding standards respect and so on)

• If you program with Eclipse, you could use Mylar. This plugin keeps track of all the classes that you modified in the context of programming a given feature. That way, when you get your green bar, you can be confident that you got all the modified resources at hand.