Unit tests and the emerging characteristics phenomenon

The scientific theories about the complex systems like weather, biological brains, social groups and ant colonies often talk about the emerging characteristics phenomenon. The complex systems tend to demonstrate a complex structure and behavior. It is usually difficult ( or even impossible) for humans to map the observed system behavior to a number of low-level intra-system interactions.

We may have a good knowledge about the characteristics of the simple
building components of the system and about the observed behavior of the system as whole, but it’s difficult to analyze the dynamics. The large number of simple components interactions within the system forms the complexity of the system dynamics. The system demonstrates behavior characteristics, which are far beyond the characteristics of a simple building component.

Software systems may be considered as such complex systems. Although much simpler than the human brain, there are software systems, which are complex enough to be analyzed by a single man as a whole. The standard way to guarantee the quality of the software systems today is to perform post-quality control activities. It usually involves the QA division members, who perform a number of manual or automated tests upon the system as a whole. The effects observed are classified as expected or defects. Then the defects should be analyzed and mapped to specific simpler building components in order to be fixed. It is often not trivial to say if the defect observation is due to static or collaboration issue, if this is a design or coding issue. It is often difficult to find the exact problematic code section. And what is always valid is that this process tends to be slow, inefficient and expensive. Organization, often do not try to analyze the defect injection reasons. They are not trying to optimize the development process and to minimize the cost of the post-control activities. However this is another story.

My point of view is that most of the post-quality control procedures, which act upon the system as a whole, can’t on their own output the quality that we want. A major reason is the complexity and the emergency characteristics phenomenon. The integrated system has a complexity far beyond its simpler building components. What, if we add another approach to our currently used defects-prevention methods. It will be beneficial trying to decrease the defects injection rate before the system integration. It is just much easier to control the quality of the simplest system component. And we have a good candidate tools. Unit tests theory is a good way to control the quality of the simplest system components. It’s even better - unit tests focus the developer over the vital component usage issue thus helping to produce better low-level design.

A major argument against using unit testing is the additional development overhead. After all it costs money and time. The first answer that comes to mind is “The quality costs money”. Unfortunately, this answer will not convince managers to invest a bunch of money in another quality- control methodology. However, it is not quite true that unit testing increases the production cost .Unit testing actually will decreases the total cost of the production cycle by reducing the cost of the refactoring/changes, reducing the defect-injection rate thus making the post-quality control activities cheaper. It makes developers feel sure about their code thus motivating them to innovate.