thekua.com@rest

I was in a situation this week, where I have been fixing bugs in one particular part of our system for total of two weeks. This situation was created by too many reasons to really list (or perhaps warrants its own separate entry) and is a relatively unusual circumstance for our project since a maximum of two days is all we tend to need for each iteration. Being immersed in ‘maintenance mode’ for so long has really highlighted the different set of skills you tend to draw upon in contrast to our normal operating mode. It has also brought to my attention a few issues that can really help or hinder you when working in this mode. Here’s a few of them:

• Good logging statements (being careful not to damage the readability of code) that detail the complex state of a system in a readable is definitely helpful as you don’t need to add them yourself or to your debugger.
• Fast unit tests help to give early feedback when making changes to the system and a change breaks its contract with other components.
• Fast integration tests gives you the confidence that your system will continue to operate as it has in your production environment.
• Identifying a bug in business requirements before code is written is definitely cheaper than fixing it later on.
• Poor exception handling can mask the original source of error. For example, on a previous project, I remember the overly complex exception handling architecture triggered a NullPointerException when handling a simple business exception.
• Code smells tend to become even more offensive as you wade through its source, which at least helps to identify areas that are good candidates for heavy refactoring or redesign).
• Repeatable test scenarios for a reported bug which are then translated into code are important against protecting against regressions.
• Though I agree with the whole philosophy of self-documenting code, I still find comments are important. I find the best ones tend to explain why a block of code was written in a particular way instead of another or the potential side effects changing that may have.

The term ‘unit test’ was being thrown about today at work but so many things about its context were just plain wrong. Just because our testing framework is called xUnit and each method happens to be called testX doesn�t make it a unit test. People have spent (far too much) time attempting to classify all types of tests coming up with categories like functional, acceptance, integration, or unit-integration tests. In my humble opinion, I tend to think of all tests falling along a spectrum, with unit tests (those that test just enough) on one end and the functional/acceptance tests (those that test too much) on the other.

Each test along this spectrum is important but the speed and quality of these tests will be one of the factors that determine how fast you can change or add to your code base. By all means, slower, bigger tests further along in the spectrum can be substituted for faster, lighter unit tests, but its consequences usually lead to a project that is less agile and more waterfall-driven.

Here are a few signs that your tests may be masquerading as something more than just (better, and faster) unit tests:

• Your application must be �deployed� to run some of your tests;
• A user must interpret console output or some other type of result for the test to fail;
• Each test takes too much time to run (it should be possible to many of these within a second);
• Excessive amounts of set up are required for each test (a smell that this might be integration test and/or testing too much); and
• Tests cannot be run without some external resource (such as a database, specific computer or some file);