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
signature.asc
Description: This is a digitally signed message part.
