Setting up a Quality Team within KDE
apaku at gmx.de
Tue Apr 17 09:40:11 BST 2012
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.
More information about the kde-core-devel