The demo I was giving in my latest iteration planning meeting was going just fine. I showed off all the improvements made in the last iteration and enjoyed seeing expected positive reactions to some of the UI behavior. Then, the customer, a title which here actually refers to my very technical mentor who is really just playing the part of the customer, asked to see what tests I had in place for the GUI logic.
FULL STOP
Oh. Right..well, about that...
I was caught uncharacteristically red-handed. In the fun and challenge of experimenting with a new library and working on the 'front-end' (something I've very rarely done in the past), I lost sight of the important truth:
The only way to go fast is to go well. (Robert C. Martin, Clean Architecture)
For the last few days I've employed a visually-driven style of development, using my eyes to verify things were correct. I started by building a small prototype, but neglected to learn from that experience what I needed in order to graduate from "prototype mode" and begin methodically creating what should have been production-grade code, paired with a thorough suite of tests.
I had set aside the discipline of TDD, justifying the situation with the thinking that user interfaces are just hard to test (so why bother?).Oh, deep down I knew there was plenty of logic that merited tests. But it really did take me a few days before I got a grip on how I would separate the code that should definitely be covered by automated tests from what probably never would.
As the end of the iteration loomed I was getting closer and closer to a working app, but all the while test coverage declined. (Perhaps the root of the trouble had been my original estimate. This probably should have been broken into a few stories, one of which could have been building a prototype.)
So, now I have a mountain of front-end UI code full of logic and it's not under test. In the event that new features are requested that require modifications to the GUI, what prediction would you make about my future velocity?
AWKWARD PAUSE
Well, the next task is to integrate persistence into the application, saving games and their sequence of moves to support resuming of unfinished games in future playing sessions. I don't think the externally visible behavior of the UI needs to change as part of implementing this feature, but chances are good that the way the UI is interacting with the game will.
So, I've begun the process of regaining control of the code by wroting several test suites. Not surprisingly, doing this uncovered some code rot (barely 3 days old!) and allowed me to refactor a few GUI components without fear. I'm feeling better about being a bit more on track.
In the meantime I've got some technical debt to pay down.