Software systems are built from units of collaborating classes.
These units are often referred to as software components and an
essential activity within the software development
process is the testing of these components, however this activity
is often neglected.
Most developers acknowledge that unit testing is very important,
but at the same time report that unit tests are seldom available
within their projects. Why is this? The answer has two parts:
Firstly, development teams are under such pressure to meet delivery
deadlines that in the rush to implement new features, there is never
enough time to write enough test code to achieve sufficient
coverage. Secondly, there is the issue of know-how. Software
developers taxed with first having to understand and then implement
complex business requirements have enough to do without also being
expected to know how to test an EJB component running in a J2EE
container, or a JSP in the web-tier, or a Java bean on a remote
Each development team should include a test programmer to work in
parallel with application programmers to produce unit tests for each
component. If the requirements and interfaces are well defined one
can write unit tests for functions that are not yet implemented. In
this case, the task of the developer is to write code for a new
feature until all test cases successfully pass.
Unit testing is a quality control (QC) activity that exercises an
application from the inside out - at the component level. Quality
assurance (QA) exercises an application from the outside in - from
the perspective of the end user. QC should logically proceed QA
since it is not the purpose of QA to find bugs, but rather to
provide feedback to the development team for fine-tuning the
appearance and behavior of the application. Any software defects
discovered by QA must be fed back to development for correction.
These feedback cycles cost time, money and aggravation. It is
therefore highly desirable to detect and correct bugs in the
Unit-test software effectively becomes an extension of the
application. The principal clients of unit-test software are
application developers; however QA engineers will also want to run
the complete set of unit tests every now and then, especially during
the integration phase and after deployment at the customer's site.
The return on investment (ROI) from unit testing is excellent
considering the following benefits.
- Early identification of design errors prevent major costs from
- Continuous feedback is available to project management for
measuring real progress.
- Aggressive code changes in the refactoring stage can be made
without introducing defects.
- Quality improvement is incrementally added to each subsequent
- Developers are able to work faster knowing there is a
test-suite to serve as a safety net.
- The project is always ready to deliver working code, even if
timing does not coincide with release date.
- Stress on team members is reduced by avoiding last minute
code fixes in the integration phase.
- Unit tests become an extension of the application for use
by development, QA, and deployment engineers.
- Friction between development and QA teams is reduced when
software releases are generally free of defects.
- Software stability under simulated loads can be
demonstrated to the customer during acceptance tests.
Complex applications often run in a distributed environment
consisting of clients, web-servers, application servers, enterprise
integration systems, and database servers. Each of these
environments requires different testing frameworks and programming
techniques. Therefore, make sure your team includes programmers who
know how to unit-test the application.
The purpose of this column is provide a summary of the content
that appears on the left.