[postgis-devel] Out of DB regression tests for ST_AsGDALRaster

[Paul Ramsey]

To the extent that you can use CUnit, please do. Cunit tests are
vastly easier to debug and work with, IMO.

On the whole topic of raster image regression testing, I'm worried
about any test that tries to do things like that, because platform to
platform rasterizers give subtley different answers, even using the
same versions. MapServer is largely lacking regression tests because
of issues in trying to compare "almost the same" image outputs. I
don't want to get into the position of Mapserver where the regression
suite is not looked at (I ran it, once, and 25% of the tests failed)
by most developers because it doesn't consistently pass on different
platforms and versions. I'd rather not test the parts which are
unstable than put in tests for unstable things and have that cause us
to stop using our whole suite. Anyone anywhere should be able to check
out postgis from SVN, build and run and get 100% regression passes.
That condition must be sacrosanct.

P.

On Sun, May 22, 2011 at 9:36 AM, Bborie Park <dustymugs at gmail.com> wrote:
> On Sun, May 22, 2011 at 9:26 AM, Bborie Park <dustymugs at gmail.com> wrote:
>> On Sat, May 21, 2011 at 7:54 PM, Paragon Corporation <lr at pcorp.us> wrote:
>>> I'm not sure what others think of this.  I would be okay with testing with
>>> python.  In fact I think raster already has some out of db python tests.
>>>
>>
>> There are some C tests for the api and wkb output but everything else
>> looks to be in-db tests.
>>
>>> Ideally though:  It should follow the same tests we do for the rest of the
>>> system and for that we use Cunit to do out of db tests.  If that's too much
>>> of a hassle for your tests, then I would personally be okay with you using
>>> python scripts since that's a requirement to use the raster2pgsql.py anyway
>>> so you actually already have to use python to test your raster2pgsql loader
>>> anyway.
>>>
>>> +1
>>>
>>> Wait for rest of PSC folks to make their comments. (HINT HINT PSC)
>>>
>>
>> I completely forgot about using CUnit.  I'll take a look as I'd rather
>> use C instead of python.  I'm trying to avoid python as that is yet
>> another dependency and the hope that eventually someone will write a
>> C-based replacement for raster2pgsql.py.
>>
>
> I took a quick read of the wiki page for CUnit.  If anything, the
> files testapi.c and testwkb.c found in raster/test/core may want to be
> rewritten to make use of CUnit.  Though I could use CUnit to test
> functionality through postgresql, I'll take baby steps and see about
> writing a shell script or expanding the capabilities of
> regress/run_test.
>
> -bborie
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>