[postgis-devel] CUnit

Mark Leslie mrk.leslie at gmail.com
Tue Dec 16 15:28:22 PST 2008


Agreed.  I haven't worked with cunit much at all, so I can't speak to 
the technology, but unit tests are worth their weight in blood, sweat 
and beers.  It would be a huge effort to write tests for all existing 
functionality, but I think it would be reasonable to require new 
functionality to have decent test coverage.  Then we can add tests for 
existing functionality as we fix it.

Hard-coding the path seems like an immediate problem.  Just grabbing 
cunit with apt-get I see that it installed into /usr as I would expect. 
  If this is definable in configure it won't be a problem.

Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com


Kevin Neufeld wrote:
> I think having the ability to perform unit tests is, as you say, 
> invaluable.  As the code base grows, it becomes harder to manage / 
> easier to break some portion of the codebase that depends on other 
> portions.  If we can swing it, I vote to introduce the harness.
> 
> We could add a "make code-check" or something to the main Makefile.
> 
> -- Kevin
> 
> Paul Ramsey wrote:
>> FYI, I've committed in the early bits of code on my line crossing
>> project. Most interesting to the development community is the contents
>> of 'cunit', which is a cunit test harness directly working on
>> liblwgeom. It was really invaluable for testing the code, I must say.
>> Good work Mark on breaking out liblwgeom, it has all worked as
>> advertised so far.
>>
>> I'm interested in thoughts on how we should handle cunit tests, or if
>> we should even have them at all. Right now there is a hardcode
>> dependency on have cunit installed in /usr/local, but obviously it is
>> still early days.
>>
>> Paul
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list