Read a brilliant and very apt article on
Functional testing by
Tim Sutherland. The article makes a case of why functional testing is more important than unit testing in some applications specially those that do not have complex algorithms or
APIs in the code.
The application I work on at my workplace is a case in point. It's a highly data centric, legacy,
ETL application written in Java. Most of the code does not have any complex business logic that requires testing at a unit level. In fact it is the integration of the tiny java components and how they collaborate during run time that contributes to the complexity of the application. In the last 2 years that I have worked on this code, I have seen very few cases where a bug could have been caught during unit testing. Typically, most defects occur due to unexpected or bad data.
In such cases, I strongly agree with the author of the above post that a small, carefully written set of functional tests is more useful than unit tests. We can run these tests nightly as part of continuous integration and also for smoke testing during every release.
I do think, however, that at the unit level, a test driven approach might still be useful. So when I am writing, let's say, a
DAO, I can write a few integration tests first for testing the
DAO. Even in such cases, hard core unit testing (with mocking etc.) does not yield much benefits. These tests could be reused later for low level integration testing of individual components. But they need not be run regularly as part of the continuous integration process to save time.
--------------
