Testing To Stop Pain

Unit testing has taken the entire developer world by storm. The xUnit frameworks are simple and easy to use. I always have a test to verify any of my code. I love it. Recently, I've been using the unit testing framework for more than just unit testing. My view on testing has been to simply stop pain.

What does that mean?! It sounds like another meaningless mantra to beat developers with! Heaven forbid! But, I don't mean it that way. Pain to me is anything that detracts me away from my task. Bad design, crufty frameworks, and buggy code are painful. Unit testing is meant to fix the latter, but what about the first two? Could we do something about them? I think so.

The xUnit frameworks are so simple. They're really verification frameworks. If we change our thinking on what we verify, we can create a richer set of tests that go beyond mere broken code insurance. At work, if anything starts feeling problematic, I start thinking how can I fix it and write a test so that it never comes back. It's automating verification of problems. I take this beyond buggy code. I've so far used it to ensure deprecated frameworks are not used on new code and to support code coding habits (like ensuring file handles are closed). I plan on using it to ensure code is deployed correctly, raising flags on poor designs via metrics, and so much more. I'm basically thinking about using testing for prevention as much as verification. The xUnit frameworks are perfect because most of the hardwork has been done to integrate them into every IDE known to developers. A red bar means I need to go look at something. If a developer is sloppy enough to clean up their system resources, I want to know. Besides, a test can also have comments to give possible explanations why it failed. What a perfect training opportunity and no one has to lose any skin off their teeth for it. Think of it as a teacher and a kind enforcer of your teams coding rules. The point should be automating pain away so that once we fix it, it doesn't sneak up on us again.

Thinking beyond unit testing and code correctness is the next step. We have a lot of tools that determine the health of our project. Why not hook those into the unit testing framework as well? I'd rather know up-front if something is going to be a problem before it is. I want to stop the pain as early as possible.