Comprehensive Unit Tests

Someone at work sent this article to me.  It makes a lot of sense, so I'm recommending it here.
http://www.infoq.com/articles/Comprehensive-Unit-Test

And of course, I can't resist the urge to add my own two cents.

• A good mock object library can make your life a ton easier.  Make sure to take time to look around at what options are out there.
• Always make it clear what question the unit test is asking.  If I can't tell when a test is no longer applicable from its name or some introductory text, then it's got a problem.

Test Heurstic: Action Avoidance

In a previous blog post, I wrote about a test heuristic I dubbed the "taboo heuristic".  I've come up with a more generalized, or parallel, heuristic.  I call this "action avoidance/alternatives".   Really, it could be fit into the taboo paradigm.

Experience trigger: I was using my new LG Tone Bluetooth headset with my HTC Incredible 2 (android phone).  I got a phone call, and decided not to answer (I was deep in thought at the time).  I didn't press any buttons on the headset or phone--I was just going to let it go to voice mail.  A couple minutes later, I decided to place a call.   My phone had frozen.  The "incoming call" screen was still showing, asking me to slide up or down to pass/accept the call.  I could still see a photo of the caller, and their number.  I couldn't get my phone to respond. I finally tried to power off my phone.  A few moments later the Android OS told me the dialer wasn't responding, and asked to force kill it.  My phone rebooted (and took its merry time to do so).

Analysis: I suspect that other events helped expose the bug.  I haven't tried to reproduce it yet.

Generalization:  This fits with the taboo heuristic I came up with a while back, but may also involve state pollution as described in James Bach's rapid software testing course slides.

Lesson Learned: often times, we can focus so much on making good actions and wrong actions that we forget about the possibilities of inaction: what will the application do if we don't respond?  Or if we try to back out, or even kill the application or connection?  Or if we take a completely different action?  Or try to accomplish the same action in an unusual or unconventional way?

The whole point of the taboo heuristic was to find another way to accomplish a given task or expose a feature, or to think about a problem or test in a different way by precluding the normal set of actions so we must look for an alternative.  The action avoidance heuristic is aimed at avoiding, cancelling, or side-stepping the actions presented to us--or taking no action at all.  We let things time out.  Or, we try to work around a supposedly "required" action.

I am not sure if this is actually different than the taboo heuristic, or just another way of looking at it.