[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-dev] UI Testing (was: Planning meeting notes, July 15 2009)
|
At Wind River, we
had invested into the TPTP AGR as well as
Rational Functional Tester (RFT)
2 years ago. When
the AGR went into maintenance mode, we did an extensive survey and
tested lots of
different tools. We finally
picked QF-Test from QFS as the winner of our
evaluations.
After 1.5
years of using it, we still believe it's the best
UI testing tool for our
needs. Of course
the needs of others may differ, but for us the
main reasons
are:
-
(compared to RFT:) The
flexible and intelligent UI object recognition mechanism minimizes relearning
of UI objects even if UI layout changes (e.g. restructuring of
perpectives). Before QF-Test, the need to
re-learn the UI widget map after even simple layout changes to dialogs had
been killing our
productivity.
-
Strong script
debugging including the possibility of one-click updating expected
results of checks
-
(compared to SilkTest:) New SWT
versions are supported very early. We got "early bird" instrumented SWT
plugins at most a couple of days after requesting them. This is only one
aspect of the very responsive support we experienced by
QFS.
-
(compared to SWTBot:) The ability to include
manipulations on native dialogs is a must-have for
us.
I added QF-Test into Szymon's
table.
Feel free to ask any
questions about it. In order to offload the global eclipse-dev mailing
list,
discussing UI
testing tools - ask questions there, or CC if you
are interested.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
- For next week's meeting, please start sending status messages to McQ
again.
- Szymon has added information about UI test tools to: http://wiki.eclipse.org/Automated_Testing#UI_tests
Everyone,
please have a look at the top two tools, SWTBot and Window Tester. We should
decide as a group which tool we would like to use.
Continued raw notes
from the retrospective:
- OSGi spec was late
- questions around ramp
down policy with cross-project dependencies
- proposal: code coverage
integrated into the build
- considering a new approach to documentation
(wiki text)
- performance degradation comments need to be reset at the
beginning of each release cycle
- doc changes in RC4 broke the builds
-
split out doc tests
Boris