D a t a s t r u c t u r e s a n d a L g o r I t h m s Annotated Reference with Examples

APPENDIX C. RECURSIVE VS. ITERATIVE SOLUTIONS
96
do though is somewhat limited by the fact that you are still using recursion.
You, as the developer have to accept certain accountability’s for performance.

---

Appendix D
Testing
Testing is an essential part of software development. Testing has often been
discarded by many developers in the belief that the burden of proof of their
software is on those within the company who hold test centric roles. This
couldn’t be further from the truth. As a developer you should at least provide
a suite of unit tests that verify certain boundary conditions of your software.
A great thing about testing is that you build up progressively a safety net. If
you add or tweak algorithms and then run your suite of tests you will be quickly
alerted to any cases that you have broken with your recent changes. Such a suite
of tests in any sizeable project is absolutely essential to maintaining a fairly high
bar when it comes to quality. Of course in order to attain such a standard you
need to think carefully about the tests that you construct.
Unit testing which will be the subject of the vast majority of this chapter
are widely available on most platforms. Most modern languages like C++, C#,
and Java offer an impressive catalogue of testing frameworks that you can use
for unit testing.
The following list identifies testing frameworks which are popular:
JUnit:
Targeted at Jav., http://www.junit.org/
NUnit:
Can be used with languages that target Microsoft’s Common Language
Runtime. http://www.nunit.org/index.php
Boost Test Library:
Targeted at C++. The test library that ships with the incredibly popular
Boost libraries. http://www.boost.org. A direct link to the libraries doc-
umentation http://www.boost.org/doc/libs/1_36_0/libs/test/doc/
html/index.html
CppUnit:
Targeted at C++. http://cppunit.sourceforge.net/
Don’t worry if you think that the list is very sparse, there are far more on
offer than those that we have listed. The ones listed are the testing frameworks
that we believe are the most popular for C++, C#, and Java.
D.1
What constitutes a unit test?
A unit test should focus on a single atomic property of the subject being tested.
Do not try and test many things at once, this will result in a suite of somewhat
97

---

APPENDIX D. TESTING
98
unstructured tests. As an example if you were wanting to write a test that
verified that a particular value V is returned from a specific input I then your
test should do the smallest amount of work possible to verify that V is correct
given I. A unit test should be simple and self describing.
As well as a unit test being relatively atomic you should also make sure that
your unit tests execute quickly. If you can imagine in the future when you may
have a test suite consisting of thousands of tests you want those tests to execute
as quickly as possible. Failure to attain such a goal will most likely result in
the suite of tests not being ran that often by the developers on your team. This
can occur for a number of reasons but the main one would be that it becomes
incredibly tedious waiting several minutes to run tests on a developers local
machine.
Building up a test suite can help greatly in a team scenario, particularly
when using a continuous build server. In such a scenario you can have the suite
of tests devised by the developers and testers ran as part of the build process.
Employing such strategies can help you catch niggling little error cases early
rather than via your customer base. There is nothing more embarrassing for a
developer than to have a very trivial bug in their code reported to them from a
customer.
D.2
When should I write my tests?
A source of great debate would be an understatement to personify such a ques-
tion as this. In recent years a test driven approach to development has become
very popular. Such an approach is known as test driven development, or more
commonly the acronym TDD.
One of the founding principles of TDD is to write the unit test first, watch
it fail and then make it pass. The premise being that you only ever write
enough code at any one time to satisfy the state based assertions made in a unit
test. We have found this approach to provide a more structured intent to the
implementation of algorithms. At any one stage you only have a single goal, to
make the failing test pass. Because TDD makes you write the tests up front you
never find yourself in a situation where you forget, or can’t be bothered to write
tests for your code. This is often the case when you write your tests after you
have coded up your implementation. We, as the authors of this book ourselves
use TDD as our preferred method.
As we have already mentioned that TDD is our favoured approach to testing
it would be somewhat of an injustice to not list, and describe the mantra that
is often associate with it:
Red:
Signifies that the test has failed.
Green:
The failing test now passes.
Refactor:
Can we restructure our program so it makes more sense, and easier to
maintain?
The first point of the above list always occurs at least once (more if you count
the build error) in TDD initially. Your task at this stage is solely to make the
test pass, that is to make the respective test green. The last item is based around

---