[fdo-dev] Assertions

Greg Boone greg.boone at autodesk.com
Wed Aug 16 09:51:08 EDT 2006

[GB] See inline...

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Tuesday, August 15, 2006 9:33 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Assertions

Greg Boone wrote:
> Hi Mateusz,
> Since you are writing the PostGIS provider within the GenericRDBMS
> framework we expect to be able to build and test the PostGIS provider
> the same manner and style as the MySQL and ODBC providers. This means
> expect you to write unit tests for the PostGIS provider in a CppUnit
> style framework. 


Yes, I'm going provide well working CppUnit-based
tests for PostGIS provider. And this subject is not
influenced by my inclination use assertions.

> From our perspective, the build team are users as much as our external
> clients such as MapGuide. The build team will building the provider in
> Debug mode and executing the unit tests in Debug mode on a daily

And if the build team will get assertion catch, it does - again - mean
that there is a serious bug and the development team has to deal
with it.

[GB] The primary issue here is that we run numerous builds and unit
tests every night which take many hours to complete. If an assert occurs
and the build is halted it will have to be restarted the next night. We
try and avoid this possibility to the best of our abilities. It is
essential that we are able to build and test all our products and
collect a clear documented record of the failures and exceptions that
have occurred without requiring human interaction. 

> It is critical that all tests be able to be executed without asserting
> or throwing an unhandled exception and all errors reported through
> standard CppUnit error handling/reporting mechanisms.
> The above 2 paragraphs deal with the newly developing PostGIS
> code base. As for any modifications you plan for existing GenericRDBMS
> libraries such as RDBI, we expect that existing coding standards (as
> seen in the existing subversion files) be followed. If Asserts are not
> used in these components now then please do no introduce that behavior
> in new code being submitted.

Greg, I have to confess that this rule abut not using assertions
(I mean pre-/post-conditions and invariants assertions,
but not Unit Test assertions) is ridiculous.
It's like "please, don't run your code under debugger".
This rule dictates to not to use one of the important tool
in programmer's toolbox. IMHO without it, it will be hard and
time consuming to provide good quality of code, with high
percentage of LOC executed that means tested.

Sorry, but I can't "walk on the line" without good assecuration.
I'll use tools provided by C++ language for testing and debugging
but I'll also stick to FDO rulse about Unit Test.

[GB] Mateusz, I would ask that you respect our coding standards for
existing GenericRdbms libraries. As mentioned above, my only firm
statement about not using assertions was when discussing modifying
existing GenericRdbms code such as RDBI or GDBI. (Latitude will be
provided in the PostGIS provider code base) Since the existing
GenericRdbms code is packaged into existing shipping products such as
Autodesk Map and Autodesk MapGuide Enterprise, any submissions to these
libraries is expected to meet these existing coding guidelines. Code
that does not meet these guidelines will be rejected when submitted for
code review.

Mateusz Loskot

To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org

More information about the Fdo-internals mailing list