Red Bar/Green Bar/REFACTOR, Red Bar/Green Bar/REFACTOR ...

Ok, now I'm really starting to get the TDD realization. I've been reading "Test-Driven Development: By Example" and thinking about how I have been approaching things. I had been refactoring a small project to get it to the point where I could then start writing unit tests for it.

After reading part I of the book for the third time and starting to consume part III, I decided that the best course of action would be to forget about the legacy code and just start from scratch. And to make things interesting, I'd change my IDE at the same time. 8)

Anyway, I wrote a list of 7 small chunks to start the implementation with using TDD. The first cab off the rank was to write a Button state object that would track a button's mined, flagged, exposed and questioned state. I wrote the tests first, I wrote the code to compile and then I fixed the tests. I took large steps, but not so large that I felt I was without a net.

In the end, I had a class with 4 boolean fields and 2 methods for each field. One to check the current state and one to set or toggle the state. 50 lines of code. At the time, I really couldn't see the duplication clearly in this, but I felt that the implementation had a bad smell. I hesitated briefly on the refactoring until I gained the courage to continue realizing that I could just role back to where I started from if things got worse.

After a few minutes of adding a few things and refactoring the tests to actually test the new refactored code, I ended up with a class with 40 lines of code. I wasn't too excited about the change in size, but I had focused on the size to begin with. Then I looked over the code and noticed no more smell. It all just happened so easily.

(In writing this I want back to look at the code, only to realize that I had left 4 of the original fields in the code, so in actual fact there are only 34 lines of code.)

What I now have is a class with 5 fields, one boolean[] with 4 elements and 4 static final ints for each property of the button. But instead of 8 methods, I now have 3 methods and one constructor. The code reads better and has a certain beauty to it. All is right in the universe of my implementation and I am happy. And once I had finished, it dawned on me what the duplication was. I think I've developed an intuitive sense of bad smells without having a good concrete grasp of why I sense the smell. It was easier for me to sense the smelliness of the code than to see the duplication. Once I'd removed the smell, the duplication was obvious.

Now I can see the wisdom in ditching the legacy code. Trying to remodel something that already exists was going to be more time consuming and lots of unrewarding efforts for very little value. Instead, I'm leveraging TDD to get what I really want quickly and easily. (I feel like I'm stating several obvious observations, but I don't think that there were so obvious to me only a week ago.)

So, I must not forget to refactor. In fact, I think it will be hard for me not to hit the refactor step. I've always tried to simplify my code over the years, long before I'd heard the term refactor. Now I have an excuse for the aesthetic that I seek.