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 D. TESTING
99
the restructuring of your program to make it as readable and maintainable as
possible. The last point is very important as TDD is a progressive methodology
to building a solution. If you adhere to progressive revisions of your algorithm
restructuring when appropriate you will find that using TDD you can implement
very cleanly structured types and so on.
D.3
How seriously should I view my test suite?
Your tests are a major part of your project ecosystem and so they should be
treated with the same amount of respect as your production code. This ranges
from correct, and clean code formatting, to the testing code being stored within
a source control repository.
Employing a methodology like TDD, or testing after implementing you will
find that you spend a great amount of time writing tests and thus they should
be treated no differently to your production code. All tests should be clearly
named, and fully documented as to their intent.
D.4
The three A’s
Now that you have a sense of the importance of your test suite you will inevitably
want to know how to actually structure each block of imperatives within a single
unit test. A popular approach - the three A’s is described in the following list:
Assemble:
Create the objects you require in order to perform the state based asser-
tions.
Act:
Invoke the respective operations on the objects you have assembled to
mutate the state to that desired for your assertions.
Assert:
Specify what you expect to hold after the previous two steps.
The following example shows a simple test method that employs the three
A’s:
public void MyTest()
{
// assemble
Type t = new Type();
// act
t.MethodA();
// assert
Assert.IsTrue(t.BoolExpr)
}
D.5
The structuring of tests
Structuring tests can be viewed upon as being the same as structuring pro-
duction code, e.g. all unit tests for a Person type may be contained within

---

APPENDIX D. TESTING
100
a PersonTest type. Typically all tests are abstracted from production code.
That is that the tests are disjoint from the production code, you may have two
dynamic link libraries (dll); the first containing the production code, the second
containing your test code.
We can also use things like inheritance etc when defining classes of tests.
The point being that the test code is very much like your production code and
you should apply the same amount of thought to its structure as you would do
the production code.
D.6
Code Coverage
Something that you can get as a product of unit testing are code coverage
statistics. Code coverage is merely an indicator as to the portions of production
code that your units tests cover. Using TDD it is likely that your code coverage
will be very high, although it will vary depending on how easy it is to use TDD
within your project.
D.7
Summary
Testing is key to the creation of a moderately stable product. Moreover unit
testing can be used to create a safety blanket when adding and removing features
providing an early warning for breaking changes within your production code.

---

Appendix E
Symbol Definitions
Throughout the pseudocode listings you will find several symbols used, describes
the meaning of each of those symbols.
Symbol
Description
←
Assignment.
=
Equality.
≤
Less than or equal to.
<
Less than.*
≥
Greater than or equal to.
>
Greater than.*
6=
Inequality.
∅
Null.
and
Logical and.
or
Logical or.
whitespace
Single occurrence of whitespace.
yield
Like return but builds a sequence.
Table E.1: Pseudo symbol definitions
* This symbol has a direct translation with the vast majority of imperative
counterparts.
101