Unit Testing Examples

[A.M. Kuchling]

On 17 Nov 2003 09:10:32 -0800, 
	Tom Verbeure <tom_verbeure at hotmail.com> wrote:
> I'm not sure, though, at what level I have to write unit tests. It's
> easy to write a tests that validates the consistency of a single node
> of a graph, but the real complexity is, of course, in the interaction
> of multiple nodes.

Not too long ago I wrote a set of unit tests for a graph data type;
unfortunately the code belongs to my employer and isn't open source, so you
can't see a copy.  What I did was:

* Test basic things: create an empty graph and check that it has zero nodes
  and edges.  Add a vertex and edge; remove the vertex and edge.  
  In my case there are various accessors for .number_of_nodes() 
  and .number_of_vertices(), so I checked that they went up by one.
* Create a little graph, ~5 nodes, and test the BFS and DFS methods to see 
  that they output nodes in a sensible order.

Sancho, the testing framework I use, provides code coverage measurement, so
I used that to find which lines of code weren't exercised by the test suite
and added tests to cover more lines.  It's usually difficult to exercise
100% of the code, because error cases can be difficult to provoke,
especially if they represent an internal invariant being broken or an
external resource such as a file or server not being available, and some
trivial accessors aren't worth testing, so I'm usually happy with 70%-80%
coverage as long as the complicated methods are completely or mostly 
covered.

In my case I'm not bothering to run a very large graph as a test case,
because the little graph exercises all of the relevant branches; I'm
therefore betting that the code is OK for larger graphs, too.  If a large
graph demonstrates a bug someday, I would try to boil it down to a small
test case and add this case to the test suite.  

If performance is important, you might consider adding a performance test:
run an algorithm on a large graph and check that the running time is 
suitably fast.  This might save you from making some change that doesn't
affect correctness but results in a sizable performance regression.

--amk