Community
Participate
Working Groups
As the UI part of the CDO component grows, we would like to define mechanisms to test it, and include these in the automatic build. jUnit doesn't look like the right way to do testing, so we would probably need UI testing framework (i.e., SWTBot, Bredex GUIDancer, FrogLogic Squish...). Also, we need to know is if the build server can run UI tests.
Possible build server constraints have to be discussed!
Our goal is to test the following UI components: - ViewPart (Session View and other future Views) - Editor (CDOEditor, generated enhaced CDO Editors...) - Preferences Page - Widgets (Audit slider) - Toolbar buttons - Contributed context menu actions to other views. and ideally - GMF Diagram editors (as soon as we have support for it) This would help us polishing UI components and make it more stable for end-user consumption.
Additional interesting projects: - TPTP Automated GUI Recorder - Instantiations WindowTester - Abbot Java GUI Testing Framework Other resources: Automating GUI Testing for Eclipse RCP Applications: http://www.instantiations.com/PDFs/published/gui_testing_stp.pdf
It's so tempting to look at fancy technologies before defining own requirements :P
(blush) boy, it is! :P
Rebasing all unresolved enhancement requests to 3.0
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.