Some thoughts on unit tests

First of all, I don’t go in for the whole write a test that fails before I write any code. But I do aim for as close to 100% code coverage as I can get, again sometimes I pick and choose what I want to ignore when it comes to missing methods. Testing every getter and setter in a Java bean for 100% coverage seems like total overkill to me.

I do rely heavily on tests when it comes to regression testing – making sure I haven’t broken anything. I’ve spent time having to go through every page on a fair sized web app after every release and inevitably finding something broken that I then had to quickly patch. Once it’s patched you start the testing over again and probably find a few more things. With no way back  it ends up an all nighter. It’s not a lot of fun and testing helps prevent it.

The other reason I write tesst is that they help a huge amount when I refactor code. Like over the last few days. I’ve spent them undertaking a major retooling of large swaths of code. I’ve been pulling out all the RDBMS stuff from some user management code and replacing it with a Hbase implementation. It’s also shown me that the code was pretty tied to the RDBMS implementations, much more than I’d originally thought.

It’s not anymore, and I’m not sure I could have pulled it apart without a coherent set of unit tests. I’ll post a little on the strategy for writing tests I’ve implemented to prevent it in the future a bit later.

No related posts.