History
|
The idea to write a unit test framework came to my mind
when I read Martin Fowlers book about refactoring.
In chapter 4, Building Tests, he outlines how
unit tests could be organised and used to support refactoring.
Refactoring is - briefly explained - the process of improving
the design of existing code. But after old code was changed,
it must be made sure that everything still works as expected.
So tests have to be written that ensure that a unit of C++ code
behaves as expected. To be able to do that properly, a test framework
is needed.
While I was working on a kind
of "component framework" for Unix (especially Linux), I found
that many principles and techniques presented in the
"Refactoring Book" are quite useful already in the design phase
of new software. In the Fowlers book, Erich Gammas and Kent Becks
JUnit framework is described, so I decided to develop something
similar for C++.
Right at the beginning I forgot
to look around in the internet if something like JUnit is
available for C++. And of course, later on I discovered that
other unit test frameworks for C++ did already exists.
But after investigating what is around, I found that not all the ideas
I had in mind and not all the features I wanted to have in
a C++ unit test framework are realized in the existing
software packages. So I decided to further develop my flavour
of doing C++ unit testing: Scrunitizer
|
Refactoring
Improving the Design of Existing Code
Martin Fowler et al.
1999
Addison Wesley Longman, Inc.
ISBN 0-201-48567-2
|
Purpose
Extereme Programming Explained
Embrace Change
Kent Beck
1999
Addison Wesley Longman, Inc.
ISBN 201-61641-6
|
Now you might ask "What is the benefit of writing a lot of unit test?"
You might think that the software must be anyway tested at the end
and that writing a lot of unit test is additional burden that only
slows down your development process.
Well, if you really think that this is true, I really recommend to
read Kent Becks "Extreme Programming Book". Kent Becks points out that
"Software features that can't be demonstrated by automated tests
simply don't exist".
Almost untested units that
are later combined to more complex components (libraries or applications)
lead to the situation that bugs are hard to detect, hard to isolate
and very hard to correct without affecting other parts of the software.
Testing late means almost automatically that bugs are found late, that
cumbersome design is detected late and that the cost of fixing all the
bugs and problems is extremely high at the end. So all in all the
time and effort to complete the software will be considerably higher
when testing is done late and unsystematically than when it is done
earlier.
If software units are tested early and systematically, it also allows
to make changes more easily because you have test that tell you if
your modifications are really a step forward or not. They can assure
you that the functionality is as expected. That gives you much more
confidence in the process of development and makes findings bugs
and problems in yet not completely ready and tested parts much easier.
Here, the ideas of Extreme Programming and Refactoring
fall together. So no surprise that constant Refactoring is an
important parts of Becks Extreme Programming process.
in my opinion, not all ideas in Extereme Programming could be applied to all
development teams and to all kind of software projects.
But the ideas of constant unit testing and
refactoring are one of the strongest and most convincing
parts that should be applied wherever possible.
|
Design
|
The design of Scrunitizer is heavily influenced by design patterns,
which were made popular by the famous "Design Patterns book" by
the "Gang of Four" (GoF). In my humble opinion, one of the
most important and influential work in the are of software engineering
of the last decade.
Scrunitizer uses a lot of pattern discovered by the GoF. I.e. test cases
and test suites realize the Composite pattern, test observer - you
might guess it already - implement the Observer pattern. One pattern that
is extensively used by Scrunitizer is the Adapter pattern. Scrunitizer uses
adapters to generate test cases from plain functions, to create tests from member functions
of test fixture classes and to realize parametrised test cases.
Design pattern are primarily used to make construction of test cases as
easy as possible for the programmer while still supporting a flexible
and powerful design. Design pattern help also to realize one of
the most important design principles: The separation of concerns.
Scrunitizer is designed so that every aspect of unit testing in C++
handled by a different class family or different templates. That allows
easy extension of Scrunitizer without touching existing code.
|
Design Patterns
Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
1995
Addison Wesley Longman, Inc.
ISBN 0-201-63361-2
|
The Scrunitizer C++ Unit Test Framework
by Bernd Linowski
[Scrunitizer]
[Overview]
[Cookbook]
[Download]
[Index]
[Linosphere]
Page generated: 1 Nov 2000
(C) by Bernd Linowski
scrunitizer@linosphere.de
|
