Setting up a Quality Team within KDE

Andras Mantia amantia at kde.org
Mon Apr 16 21:52:00 BST 2012


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.

> While a dedicated team can help to get this started, I think it has to
> be the developers job to keep the tests working when they break as a
> result of changing code (which is exactly how it works with unit
> tests right now). Otherwise there's the risk of ending up with
> rotting tests which are useless.


I agree that the developer should keep an eye on tests and  automated 
tests are needed with proper error reprorting, otherwise the developers 
might not be aware of the problems or would just ignore it.

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. They don't even write unit tests. ;)

Andras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120416/c7352307/attachment.sig>


More information about the kde-core-devel mailing list