MapScript Unit Tests (Re: OGR/WKT)

Sean Gillies sgillies at FRII.COM
Wed Aug 10 17:25:18 EDT 2005

On Aug 9, 2005, at 2:29 PM, Steve Lime wrote:

> I probably should take you up on the offer (thanks), but then again I =
> should be=20
> doing that myself as well. Lemme try it myself with you and Sean as =
> sounding boards
> if that's ok. I gotta get the RFC up-to-date first anyway.
> Steve


I just committed a new test case to 
mapscript/python/tests/cases/ as an example for new 
shape/WKT tests. See the ShapeWKTTestCase class near the end of the 

If I were starting from scratch, I'd set up the unit testing framework 
differently (and better). It's a bit obscure, but coming from a Perl 
background should prepare you well ;) As it is, each file in 
tests/cases ending in * is a test module, with modules for each 
of the mapscript classes. Any of these can be executed like

     $ python


     $ python -v

for more verbose output. The main() method of the module runs all the 
test* members of every TestCase-derived class in the file. Adding a new 
test is as simple as writing a new class, and is automatically added to 
the test suite. There is a script called in tests/cases 
that aggregates the tests in all modules, and can be run like

     $ python -v

For my convenience I have made a shell script in my mapscript/python 
directory which cd's to tests/cases, runs all the tests and returns to 
mapscript/python. This allows me to make a preliminary build of 
mapscript, and then test this same prelim build

(from mapscript/python)

     $ python build
     $ ./runalltests

These Python mapscript tests are not the ideal tests of MapServer's C 
code, but will improve along with improvements to MapServer's C API 
that allow us to shave away the code in the SWIG layer.


Sean Gillies
sgillies at frii dot com

More information about the mapserver-dev mailing list