Skip to main content

2 minute read - Agile Evil Tester

Tracking TDD mistakes so I can fix them

Mar 1, 2008

Previously I made some TDD mistakes. So to fix them. I tracked them.

I tracked the mistakes by creating an index card that listed the ‘bad’ things on one side, and the ‘good’ things on the other side. Then noted when I did the bad things, and when I did the good things. The writing of these statements seems important. So if we have a look at the card…

Mistake Tracking

I write the ‘bad’ things in the leftmost Column “Replace”.

And the ‘good’ things in the rightmost column title “With”.

The act of marking when you do them becomes so annoying and embarrassing that you really do build the motivation to stop.

Those that particularly annoyed me I put a big X against or started using a bigger pen.

The hardest part of this process becomes maintaining the discipline to mark down when you did or did not do something as this type of reflective behaviour takes practice to build up.

By taking notes of what I did ‘wrong’, and ‘right’. I feel that I have managed to build up a reflective style of working. And I do feel that this has also had a good knock on effect on my exploratory testing note taking.

But note the important points about the “With” column phrasing:

  1. write the behaviour with a positive intent
  2. write the context of the behaviour (when? after what?)

By, write behaviour with a positive intent I mean phrase it in terms of what you want to do, instead of what you don’t so instead of “Stop committing without an update” write “Do an update after each commit”.

When I think I finally got it, I added a … in the with column. If I make the mistake again then I’ll start a new card with the old behaviours and the new behaviours, and I’ll date the old card.

The list of positive behaviours:

  1. Create ClassNames with UpperCase First Letter
  2. Refactor Automatically
  3. Drive Manual code changes with tests
  4. Check Code coverage After Refactor
  5. Review code and Add Additional Unit Tests After Refactor
  6. Do an Update After Each commit

You will need a Github account to comment. Or you can contact me with your comment.

I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, etc.