My Novice Mistakes in Test Driven Development

Since I generally present myself as a tester, coupled with my relatively novice status when coding in Java using TDD. I don’t mind writing up my TDD mistakes here.

My basic set of mistakes

The basic set of mistakes I have made recently consists of:

1. Class Names start with an upper case letter

• Doing refactoring when I don’t
• Not checking my code coverage
• Not doing a review step
• Not doing an update after a commit

So those mistakes in more detail:

Class Names start with an upper case letter

I don’t know why I kept forgetting this. Every time I created a java class I would start it with a lower case letter. For some reason I used lowerCamelCase instead of WikiCase.

Possible reasons:

1. Java does not enforce this and I didn’t have a style checker installed into Eclipse.

• A constructor looks like a method and methods start with a lower case
• I do too much scripting

But, really the reasons mean nothing. We only get points for getting rid of the habit.

Doing refactoring when I don’t

The basic TDD process flow:

Failing Test -> Passing Test -> Refactor

I get full points for:

1. using Eclipse to create classes by writing an instantiation line in the test and then using ctrl+1 to create a new class using the Eclipse wizard.

• writing short lines of test code and driving through to production code. (creating methods with ctrl+1 again)
• and repeating

And then I hit ‘refactor’.

I thought I refactored, but instead I ‘rewrote’. I introduced new lines of code which I did not drive with tests and which the original tests did not cover. And I introduced new bugs as a result - even though the old tests passed.

I did not refactor, and those new lines of code should have meant new tests.

Not checking my code coverage

I wrote a whole bunch of code with a whole bunch of tests and then when I eventually ran code coverage I didn’t get 100% - hey, what gives.

Some of the additional lines of code resulted from my rewrite ‘refactoring’. And some of it because I had test driven my code with higher level acceptance tests, and then forgotten to drop down to TDD my class level code.

By reading the results of my code coverage I could spot tests that I had missed out. Which I would not have done, had I done TDD better.

Not doing a review step

TDD demands intense focus (at least it does for me) and at the end of a session when I have my code and my tests pass and I’ve ‘really’ refactored. I find it so tempting to just hit the ‘done’ button.

And I did.

But I shouldn’t.

I should have reviewed. I should have stepped back and gone ok, so I’ve met the acceptance criteria, but maybe I need some unit tests.

• What exception conditions might I encounter?
• Why did I not handle nulls as parameters?
• Why did I not think about those special cases?

As a tester, I think about those things when I review stories. Exactly those kind of things. I did not manage to swap well between test and developer modes when learning TDD.

Not doing an update after a commit

A killer mistake if you work in a team environment. Stick your code into the repository but then not get the changes that other people have made.

My Excuse? I do most of my coding at home on my own so I don’t normally have to do this step.

I got lucky lucky lucky. I wasn’t pairing at the time, but my pair spotted it during our next pairing session.

In the next exciting episode…

I will describe my approach to tracking mistakes and what I’ve done about them.