SWT Test Plan
We have four different kinds of testing activities which need to go on
during a test pass:
- Platform tests - Eclipse is now running on a large number of
platforms. We need to ensure that all ports are functioning on at least
a representative set of locales. To do this, you need to install the latest
drop on a machine running the appropriate "os/ws/arch + locale" combination,
and then use it long enough to get confidence that the platform is working
(hint: Pay specific attention to locale specific issues.). You should do
at least the following:
- do all steps required to open a self-hosted eclipse.
- run all the swt examples
- Eclipse look&feel tests - The first experience people have
with Eclipse is SWT. If SWT has cheese, flash, performance problems, etc.
then people will write Eclipse off before they even get to the point where
they understand how powerful it is. We absolutely have to make sure that
the Eclipse UI is working as well as we can make it work. To do this, you
need to fully exercise the Eclipse UI: every possible menu, dialog, and
window needs to be displayed. You also need to be "brutal" with the UI by
doing things like:
- resizing while things are repainting,
- forcing other apps to cover and uncover the Eclipse windows,
- dragging another app's window around on top of Eclipse,
- opening every view in a single perspective,
- etc.
- Coverage tests - These tests ensure that SWT as apposed to
Eclipse is working correctly. Some of this testing is covered by the automated
test suite, but those tests do not detect appearance or interactivity problems.
You need to run as many tests as possible which exercise the SWT API. The
SWT examples do some of this, and these tests are publically available.
The SWT committers also have access to a set of internal tests which we have
been not been able to open source for a variety of reasons. You (if you are
a committer) should run these tests as well. Any other SWT code which you
have which is not Eclipse should also be run.
- "Pride in my work" tests - For the SWT committers in particular:
The code you write/release is your responsibility. You need to be confident
that this code is working properly. Please ensure that you test all major
areas of functionality that you "own".
I strongly encourage everyone who reads this to provide as much help
testing SWT as you can. If you do decide to help, please send
Mike_Wilson@oti.com a note indicating
which of the above testing activities you will be doing. One good area to
contribute is in locale specific testing on locales other than German and
Japanese.
For all testing, make sure you are using one of the supported platforms
from the R2.0 plan.
Remember that, the first test pass lasts from May 22..24. You need to
provide feedback during this window if you want your inputs to be useful.
To the SWT committers, here is a list of who should cover what (note: "Pride
in my work" tests are your own responsibility):
- Steve - win32 coverage tests (if you're around)
- Boris - gtk platform & coverage tests
- Grant - motif coverage tests (aix, solaris, hp-ux)
- Silenio - motif platform tests (aix, solaris, hp-ux), photon L&F tests
- Veronika - win32 coverage tests
- Carolyn - win32 coverage tests
- McQ - WinXP L&F tests
- Felipe - motif platform & coverage tests (linux), photon platform & coverage tests
- Christophe - win32 platform tests, launcher platform tests (include GB-18030)
- Lynne/Knut - StyledText "Pride" testing only.
- Kevin - launcher L&F tests (good error message handling (and good messages), etc.), solaris/motif & hp-ux/motif L&F tests
(shout if I missed anyone. ;-)
Curtis & Jason (SWT co-ops) you guys should do Eclipse L&F testing
on win32, linux/motif, and linux/gtk. You can split up the work however
you want.