jonathan: thuban/test test_baserenderer.py, 1.10, 1.11 test_layer.py, 1.34, 1.35

[Bernhard Herzog]

Jonathan Coles <jonathan at jpcoles.com> writes:

> Am Donnerstag, den 17.02.2005, 13:54 +0100 schrieb Bernhard Herzog:
>
>> This change breaks the test suite because Thuban.versions imports
>> wxPython which requires X.  Maybe it works with wxPython 2.5 where some
>> initialization is delayed until wx.App is created and the test suite
>> doesn't do that.
>
> gah! i had even run across this. no, it doesn't happen under 2.5. 
>
> do you have any ideas what can be done about depending on the wxPython
> version?

The reason the tests now depend on the wxPython version is that gdalwarp
produces output that depends on the version.  Now, AFAICT the only
reason wx.h is included by gdalwarp.cpp is version checking and that is
only needed to determine whether to invert the bitmask and whether it
supports a real alpha channel.  

The solution seems obvious then: make those two flags parameters of
ProjectRasterFile.  That way the return value of ProjectRasterFile does
not depend on the wxWidgets version anymore and you can always test all
reasonable combinations of those two flags.  It also makes gdalwarp
independend of wxWidgets once again.

> btw, if baserenderer shouldn't depend on any gui, perhaps it should be
> in Model/?

One reason it's in UI is that it started out as part of the wx-specific
renderer.  Another is that IMO rendering is not part of the data model.
Ultimately, I think, we should refactor Thuban into more than just Model
and UI.  Something more like Thuban.Data, Thuban.Map,
Thuban.Interaction, Thuban.UI and perhaps Thuban.Renderers and more.
Thuban.Interaction would be the non-GUI toolkit specific parts of
Thuban.UI.

We should also consider separating "Thuban the application" from "Thuban
the library" a bit better.  The library should be only about mechanism,
any default policy would be supplied by the application.  E.g. some code
in Thuban.Model knows where the user's projection definitions are
stored.  That kind of thing should be decided by the application, not
the library.

> although some things in the tests do assume a gui of some
> sort...at least a DC...

That's why there's the MockDC and the SimpleRenderer in
test_baserenderer.py.  The do not depend on wxPython at all and only
provide the interface the baserenderer needs.

> maybe there should be two different test suites:
> one for purely Model code and one for UI code.

That would be useful, too.  The main reason for not allowing any GUI
code to be used in the tests is that importing wxPython requires a
working X connection.  That will be fixed for the most part with
wxPython 2.5 apparently.  However, if we do add test cases that really
need wxPython, they should be separated from the ones that don't.  Not
sure how to organize that, but they should at least be in different
files.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/