Discussions

How is unit testing performed in organizations? Is it an informal activity that is done before integration if there is some time left after programming or is it the key element of the development effort? A recent poll examined the way unit testing is performed in software development organizations. Here are the results:

Unit testing is not performed 13%Unit testing is informal 46%Unit tests cases are documented 11%Unit tests cases and their executions are documented 16%We use a Test Driven Development approach 14%

Participants: 460

As we can see, a majority of participants is still performing unit testing informally. This is symptomatic of the small consideration that is given to the testing phase in most software development projects. When the pressure to deliver on time is big, an informal unit testing phase allows mainly to test poorly without being noticed. It is however recognized that unit testing is an important building block of system quality and that it costs more to correct errors discovered in later project phases. Good documentation of unit tests allows also improving maintenance when the original developer has left the project or the company.

At a time where agile approaches repeat the importance of unit testing, the glass can also be considered as half-empty. From this point of view, It is already encouraging to see that 41% of the participants are documenting their unit testing efforts. A Test Driven Development approach is used by 14% of the participants and 16% are documenting the execution of their unit test. These percentages are already important. They could be explained by the emergence of a wide range of open source unit testing frameworks in the xUnit family. They are the tools that should lead to more and more repeatable unit tests.

There are different kinds of software and they need to have a different way of testing. On Java forums there are a lot guys who think that a unit testing alone could make your programs work better but in fact in most cases its hardly can help them to write better code (but this can improve their confidense so they will sleep better and thus write a better code :)). They test getters and setter. They test trivial methods. In fact often the tests for these methods are longer than the methods itself.

When you are developing a prototype testing can even hurt your project. In XP this is called a spike solution.

I think only things that really might be broken must be tested. For example if you have a complex algorithm, some part that depend on a buggy component or a interaction of components created by different developers, but average java application (I think it is a database with a web back end) contains almost no such a code. So in most cases it's sufficient to have only a informal testing.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.