Unit Test Slacker

It is crunch time. QA logs a critical defect and it ends up in your queue to fix. A few clicks, key presses, and browser reloads later, your fix is ready to commit for the nightly build. Happiness is fresh code. You even remembered to test out the change...or did you?

I admit, I can be a slacker when it comes to unit testing. Happy path all the way. But my freewheeling, cowboy testing day came to a halt when my code change impacted more than I thought. Yep, I did not fully test my couple lines of code, hitting all the possibilities to make 100% sure I did not break something.

The problem was simple: the front end sends the data to the server via a POST of JSON data. The form input value was formatted as an array, a generic way of dealing with the possibility of multiple responses. The server side code, however, expected a simple value. A quick arrayToList() and the form was humming along.

In my enthusiasm, I updated more than one line in the code to use the new (hackish) approach. In my drive to close out the ticket, I only tested the documented problem, ignoring the tests for the other extra lines. Come the morning, I had two new issues documenting related problems...problems I created.

Lesson learned: if you change it, test it.

First Steps into Test Driven Development with Red Green Refactor

I (finally) took my first dive into test driven development (TDD) with a personal project I recently started. I admit, the first thought that came to mind when I first read about the red/green/refactor process included a man, flannel, and duct tape. ;-)

I decided to use MXUnit for my unit test framework. Using the Eclipse plugin made running the tests very easy.

Instead, the hardest part for me was fighting the impulse to just write code. Red/green/refactor is all about first writing the test, watching it fail, then writing the code. Test, fail, code, and repeat until the test passes. Several times I caught myself writing code outside of the confines of the current test case. It was far too tempting to listen to the little voice that says, "It will be easy to add this feature too. The template is open anyway."

Writing the tests first was also a challenge. I had to sit back and really think about what behaviors and data my user bean would contain. I actually had to formulate a plan before coding! Time to practice what I preach about on almost a daily basis at my paying job.

I have yet to get to a true refactor stage, but I imagine it will be soon. It is too early in the unit testing and coding phase to have enough code to refactor.