[geos-devel] Unit Tests organization

Mateusz Łoskot mateusz at loskot.net
Wed Mar 8 03:31:09 EST 2006


Hi,

Continuing discussion about Unit Tests for GEOS I'd like
to present next ideas and ask some questions.

First, anyone interested in Boost's Unit Test Framework usage in the
bigger picture, please refer to following posts I sent on the Boost
lists. There you'll find some tips about how to organize physical and
logical structure of tests.

What's best practice to incorporate Boost.Test in own project?
http://lists.boost.org/boost-users/2006/03/17800.php

How to organize my Unit Tests?
http://lists.boost.org/boost-users/2006/03/17804.php

You can also find those posts through Gmane gateway:
http://news.gmane.org/gmane.comp.lib.boost.user

I'd like to recommend Gennadiy's posts as IMHO including best ideas.
For your information, Gennadiy Rozental is the leader of Boost.Test
libraries development.

Here are those posts I'd recommend:
http://lists.boost.org/boost-users/2006/03/17825.php
http://lists.boost.org/boost-users/2006/03/17827.php



OK, next I'd like to move to organization of particular Unit Tests
in GEOS. Obviously, Boost UTF based test follow quite different approach
than those for JUnit (currently implemented for JTS).
I'm not a Java programmer but as far as I revealed, JUnit tests are
divided by-class: every test modul (.java file) is dedicated for single
class.

In Boost UTF (what you can read in posts referenced above) there are
two levels:
- test implementation (.cpp file)
- test executable module (building output as binary file) - Test Module

Every single implementation file (.cpp) will produce single
executable. Next, in that single .cpp file you can define a number of
tests cases and/or test suits organizing a number of test cases.
Example in pseudocode for simplification:

// my_test_module.cpp
TEST_SUITE_START( first )
TEST_CASE( one )
TEST_SUITE_CASE()

TEST_SUITE_START( second )
TEST_CASE( one )
TEST_CASE( two
TEST_CASE( three )
TEST_SUITE_CASE()

TEST_CASE( standalone_test_case )
//...

Finally, my_test_module.cpp will produce one executable file and
will allow to run a bunch of tests defined inside.


Now, I'd like to hear your suggestions about how to organize (slice)
test cases/suites in test modules? According to what criterion?

Simple tips proposing by Gennadiy (from Boost list posts):
"You could have any number of those [tests] in a single test module.
You could use your own judgement to decide when to split your test
module into separtate executable.
Usually reasons more or less clear:
    * Different units/subsytem needs to have separate executable
    * If some feature may casue compilation error - move it into separate
module.
    * If number of test module execution time exceed some limit (your
choice) - split it."


According to my current knowledge of the structure of GEOS, I'd propose
following ruls of organization of tests:

1. Test of every geometry primitive (point, coordinate, envelope,
linestring, etc.) will be defined as separate TEST SUITE (with Test Cases)
2. All Test Suites for geometry primitives can be stored in single .cpp
file -> run from single executable file
3. Possible approach for other classes is to organize Test Modules
according to namespaces (one namespace = one test module). Test of
classes for single namespace may be organized into Test Suites includin
a number of Test Cases for testing such class.
4. Every algorithm from \source\algorithm could be tested in separate
Test Modules or related algorithms could be grouped into one Test Module.
5. If single class or namespace (related classes) requires external data 
source (e.g. XML file) to do tests then such test should have be run 
inside separate executable  -> defined in separate .cpp file.
6. ... ???


Another approach is to slice GEOS by class and organize every test into 
single executable Test Module. But I'm not sure if this is applicable.

Thank you for your comments in advance.
They would be very thankful to organize tests in clear structure.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net



More information about the geos-devel mailing list