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:
- 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:
- 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:
- 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.
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.