Setting up a Quality Team within KDE

[Andreas Pakulat]

On 16.04.12 23:52:00, 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.
>  I agree, it is also easy to break a unit test, but the problem is the 
> above, as for a regular C++ developer user visible string change is 
> safe, while from Squish test point of view might be not.
>  The same is true if you reorganize the UI e.g in Designer and the 
> objetc hierarchy is changed. With a not carefully set up test this will 
> cause major problems. With a not carefully set up test suite and a 
> dialog from a library it will cause a lot of problems in many of the 
> tests and that will be time consuming to fix.

Well, but you can have similar problems with badly designed unit-tests
(and thats what you describe above, a badly designed UI test). If the
API/Class it tests changes behaviour slightly you may end up fixing up a
lot of places too if you didn't take care of avoiding code/data
duplication in the beginning.

Andreas