Controlling Pain: Augmenting Unit Testing

I realized that I have yet to blog about my presentation at Smalltalk Solutions! For those interested, I will be giving my talk on April 26, 2006 @ 1:00-1:50pm. I hope to see a lot of people there. This is my first conference talk and I'm so excited. I'm nervous. It's an honour to share the stage with such great thinkers. I can't wait! Anyway, here's the details from my proposal:

Typically, unit testing ensures that individual pieces of an application work as expected. However, in practice this can easilylead to a state in which we settle to have just a minimum level of confidence in our code, like some sort of silly mistake insurance. But, what if we looked at testing as a means to prevent and eliminate pain, to actually increase the amount of confidence we have in our work by pointing at places where the cost of change needs to be reduced?

Smalltalk has a highly reflective and lively environment that can be used to augment traditional unit testing. It allows us to do things that are only dreamed about in other environments. We can easily question and interrogate code or any aspect of the system. It is not hard to implement tests to ensure code correctness, enforce metrics, and scrutinize resource allocations.

This power can be used to prevent pain by working inside the unit test framework. For example, you can have a metric test which, upon reaching some threshold value, presents a failure with the top offenders. Moreover, you can even check that resources are cleaned up properly between each test, and fail if proper procedure is not performed. You can even verify that private messages are not sent outside the class and that deprecated methods are no longer used.

You can be creative and take the stance of using tests to stop and minimize the cost of change. There is a large variety of characteristics that can be tested, from run-time correctness to code quality. This presentation will give real world concrete examples in Smalltalk.