Saturday, May 19, 2007

Jsunit and Smack

It's only been like an hour or so since I started applying JSunit to the Smack Code and already I've reaped the rewards. A recurring problem I've been seeing with code is that unless you have unit tests, the average person doesn't have a great grasp over the whole code base, no matter if they wrote it or not, they have no easy way to quickly revisit that lost ground. Sadly maybe I'm doomed to be average but luckily when I write unit tests i feel confident in what the code I've written produces.
Notable exceptionals seem to grasp the code base well regardless of test coverage and the trend tends to suggest that they have excellent memories. It stands to reason that freeing up that additional memory in those that have the capacity acts as a great enabler letting their efforts be better spent on design decisions. Also, my memory sucks.

After a short time of stumbling around and watching Louis Theroux, I've found that many of my elements are actually producing string representations of the HTML elements and not infact producing true elements as return types. This is a pretty obvious pitfall but somewhere in the smack code I've unwittingly converted Strings back into HTML elements. Now that I've captured this in a test, once I have sorted it I will be one step closer to understanding to the letter exactly what the smack code is doing, not what I believe it is doing. Thats a key difference with unit tests. When you capture the functionality down to the granularity of every method there is no room for error.