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

[Marco Hugentobler]

Hi Sandro

> 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.

Qt is much more than a library for widgets. We are using QString, QFile, 
QList, QMap, QHash, etc. all over the place. And also the GUI independant 
rendering is done with Qt in the QGIS core library. Last but not least, the 
GUI independant print composer classes in core are using Qts canvas and canvas 
item classes.

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

In the case of the symbology, the new one provides the functionality of the 
old one (plus more), but with different classes. I also think it is reasonable 
to drop the old tests, though a very strict testing policy would probably 
forbid that.

> 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.

Yes, that's very important. 
Outside of core classes, we shouldn't be too strict with requesting tests or 
leave it to the patch authors if they want to add a test (e.g. to avoid a 
bugfix to reoccur, as you described in your other mail).



Regards,
Marco







Am Freitag, 8. Juli 2011, 18.42:12 schrieb 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


-- 
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee