In order to migrate unit testing methodologies into a formal engineering
discipline, the methodology must be address three specific areas:
Unit Testing As An Engineering Discipline
This involves a proactive research and development phase targeting specific
areas that are currently left to a fair amount of hand waving, have insufficient
depth, or are completely absent. These areas include:
- Case Studies - The development of meaningful case studies to illustrate
the complexities and advantages of unit testing. Case studies are also
used internally as a starting point for researching automation tool
feasibility and algorithms. Case studies should include, but not be
limited to, the following development categories:
- Client application
- Server application
- Device Drivers
- Web Services
- Web development (ASP.NET)
- N-Tiered applications
- Realtime applications
- Unit Test Patterns - In order to formalize the discipline, patterns in
unit testing must be identified. Similar to design patterns in object
oriented programming, the goal is to identify specific test patterns that
match up with specific application functionality.
- Publications - Equally important is the education and acceptance of unit
testing by the developer community. This is best achieved through the
publication of articles, news releases, books, and other information related
to unit testing.
- Consulting Services - As knowledge is gained through the development
efforts in this project, the key members will most likely become experts in
the field of unit testing. A key role that we can play in the
community is to provide consulting services for companies that would like to
improve their development cycle with the application of unit tests.
- Cost/Benefit Analysis - Formalizing this process is key to the
successful introduction of unit testing into a company's development cycle.
It is not sufficient to say "unit testing reduces bugs which saves you
money". There is always a cost associated with something that intends
to "save you money". The cost of a new technology or methodology is
frequently overlooked by the programmers and difficult to quantify.
Developing some techniques for analyzing a business' current development
cycle and how unit testing may or may not benefit it is crucial.
Automation tools focus on several benefits to the developer. These
include the ability to become productive with a unit testing methodology sooner,
and the cost savings associated with reducing manual grunt work--defining unit
test classes, parameters, mock objects, exceptions, etc. Since one of the
points of unit testing is to provide a guide (in the form of code documentation)
as to what the application should do, it seems reasonable that application stubs
can be derived from the unit tests. The current thinking for automation
tools relies on creating and maintaining unit test definitions, supported by XML
Applications And Modules
This is the final stage. Unit tests have been written and the
corresponding modules in the application are being developed. Unit tests
are run frequently and become more valuable as the development effort reaches
maturity. The classic "fix it right away if it's broke" philosophy simply
does not work in a very large development effort--it is too reactionary to
problems. Rather, unit test failures need to be integrated into defect
trackers and provide meaningful information to developers in the form of email
notifications and online reports, so that unit test failures can be managed just
like any other defect/issue.