Setting up a Quality Team within KDE

[Alexander Neundorf]

On Monday 16 April 2012, Andras Mantia wrote:
> On Monday, April 16, 2012 08:59:13 AM Volker Krause wrote:
> > I don't think UI is necessarily easier to change than internal API,
> > the key  difference is that you'll get a compile error for the unit
> > test, while you wont notice a broken Squish test immediately.
> 
> I was thinking about such innocent things like changing the title of a
> message box/dialog. If the object is found by exact match for the title,
> then chaning it will likely break the testcase whenever the dialog or
> any child widget of the dialog is accessed. Eg. changing "Error" to
> "Error doing X" can break your test.

In most cases it is good enough to identify widgets via their name and the 
window they are contained in. Adding the type to it is usually no problem.
You can then easily leave out containers like groupboxes etc.
We use a macro
#define SET_OBJECT_NAME(object) object->setObjectName(#object)
to help with setting the object names.
Is there an easier way to do this ?

...
> Still I think we need a dedicated team who can create initial (nicely
> designed) tests, could assist the developers in case code changes
> require fixes that are not straightforward to do and could keep the
> tests up-to-date when new features are added.
> 
> Hoestly I don't see KDE developers all learning Squish and writing,
> maintaining test cases. 

I think so too.

Alex