[Qgis-developer] Rethinking the testing and release procedure of QGIS

[Sandro Santilli]

On Thu, Jul 07, 2011 at 11:37:01PM +0200, Marco Hugentobler wrote:
> > What has to be maintained about testcases ?
> > The only reason to change a testcase would be a change in the underlying
> > classes interfaces, which is one of the causes for instability, so having
> > testcases that break might be an aim to keep APIs stable.
> 
> I can think of several reason why the testcase need changes and the 
> maintainance is not 0 (usually there are even more cases in practice):
> 
> - The dependencies of QGIS do change (both in API and in behaviour). Most 
> tests use Qt classes. The Qt API _and_ behaviour can change. Anybody remembers 
> the switch from Qt3 to Qt4? It was a huge effort to port all the classes (the 
> bigger the testsuite, the more changes).

Not all kind of tests would suffer from this. Core functionality should
not be dependent on GUI stuff, right ? And GUI tests should be on a level
of abstraction that doesn't mess with widget library details.

> - The API of QGIS might indeed change. E.g. say Martin implements a new 
> redesigned symbology engine -> he needs to adapt all the symbology related 
> test (the more the better?)

If it's _new_ functionality you're talking about it would come with _new_
tests and the old you could just drop.

> - The 'no change without unit test' policy means also test for internal 
> classes (not in the public API)

I don't have enough knowledge of the qgis API levels to have a say
about this. Surely the policy should be more specific about at which
level tests for different components should be provided.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html