Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] howto: automating testing of workbench-based SWT UIs

summary: We have proven the concept of automating testing not only of
standalone SWT UIs, but of workbench-based SWT UIs. We seek IBMers to
take part by using abbotforswt to automate FVT of their UIs and thus
extend our codebase.

details:

In developing abbotforswt

http://w3.opensource.ibm.com/projects/abbotforswt/

(where we're parking foundational code until we get OSSC approval to
open-source) we first had to focus on SWT fundamentals. We proved that
we could automate testing of a standalone SWT UI by SWTizing Dutta's
scenario 2: see

http://www.sys-con.com/java/articleprint.cfm?id=1940
http://w3.opensource.ibm.com/project/shownotes.php?release_id=597

However our "real" objective has been to enable use of abbotforswt to
test Eclipse workbench components. (Our motivation for development is
that our "real jobs" pay us to develop UIs for WebSphere Studio
plugins.) The good news is: it works! The bad news is: even if you're
in IBM, you must post me (tlroche@xxxxxxxxxx) to see code. Our code is
contained in *.tests plugins that depend on lots of WS code; I gotta
find way to get it onto IIOSB. (Suggestions welcome.)

Anyway, the pattern for testing workbench stuff is something like the
following, which uses a (working) wizard test of mine as example. It's
also pretty raw/ugly--this is early days--so please be charitable.
<legalese> Note that the following snippets are all

Licensed Materials -- Property of IBM
(c) Copyright International Business Machines Corporation, 2000, 2003
US Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.

and available under the terms of the Common Public License

http://www.opensource.org/licenses/cpl.php </legalese>

Basically, you need to provide some UI support (if only intellectual),
then code your fixtures and testcases. For the wizard example:

* UI: instrument where possible, learn where not.

- tag widgets where possible using Widget.setData(String, String).
  E.g. in my createProjectControl()

> public static Object[] createProjectControl(
> Composite parent,
> final String cLabel,
> final String tTip,
> final String bLabel,
> Listener bListener,
> final String bTip) {

>   Label l = createLabel(parent, cLabel);
>   // instrument for testing
*   l.setData("name", "projectControlLabel");
>   Composite c = createSkinnyComposite(parent, 2);
>   Text t = createText(c, DEFAULT_TEXT_STYLE | SWT.READ_ONLY);
*   t.setData("name", "projectControlText");
>   setAccessibility(t, cLabel);
>   t.setToolTipText(tTip);
>   Button b = createPushButton(c, bLabel);
*   b.setData("name", "projectControlButton");
>   b.addListener(SWT.Selection, bListener);
>   b.setToolTipText(bTip);
>   return new Object[] {l, t, b};
> }

  (We use the name attribute consistently. We probably need API to
  abstract this.) Below I will use the tags projectControl{Button, Label,
  Text} defined above to find those widgets.

- learn useful info about your widget's context. E.g. every workbench
  wizard has Back, Next, Finish, and Cancel buttons contributed by
  WizardDialog, which is Eclipse code that I don't wanna touch. To
  find, e.g., the Finish button, I note that it's a Button
  (Button.class), its text is "&Finish" (in English--I need to hit the
  properties file), and it's in my wizard, which has frame title= "New
  Action Mapping" (same i18n comments apply).

* setUp(): for wizard testing, the sequence is something like (note
  possibly unnecessary stuff within)

- find the workbench, its Window, the Window's Shell, and the Shell's
  Display

- if necessary, create one or more projects in the workbench (most
  wizards need some context into which to do something), and any
  needed artifacts therein. (Note that one of the main factors gating
  the success of automated GUI testing of Eclipse plugins will likely
  be the ready, user-friendly availability of a large stock of
  fixtures. Your assistance would be appreciated.)

- create a StructuredSelection with which to init the wizard (using
  created project(s))

- use the Display to syncExec(new Runnable() { public void run() { ...
  }}) the init(...), create(), and open() of the wizard

- get the Shell of the open wizard (explained below)

* testcase: do a syncExec(new Runnable() { public void run() { ... }})
  in which you

- read widgets. E.g., for the Text tagged above, it's straight Abbot:

> WidgetReference ref = new WidgetReference(
> "projectControlText", Text.class, "projectControlText");

  Since I can give the Finder a tag, I don't need much else.

> Text projectControlText =
> (Text)DefaultWidgetFinder.getFinder().findWidget(ref);

  After I have the widget, it's just straight JUnit (and SWT):

> assertTrue("projectControlText not enabled",
> projectControlText.getEnabled());
> assertFalse("projectControlText is writable",
> projectControlText.getEditable());

- do things to widgets. E.g., for the untagged Finish button:

> ref = new WidgetReference("finishButton", Button.class, null, null,
> ACTIONMAPPING_GENERIC_REGIONPAGE_TITLE, FINISH_BUTTON_TEXT);

  Since I have no tag, I give more information (frame title and button
  text). (I could give less information, but that would risk Abbot
  throwing an exception if it couldn't find the widget.) I also bound
  the search ...

> Button finishButton =
> (Button)DefaultWidgetFinder.getFinder().findWidget(ref, ourShell);

  to the wizard's shell (ourShell), discovered in setUp(). I can then
  inspect the button

> assertTrue("finishButton is disabled", finishButton.getEnabled());

  and click on it.

> tester.actionClick(finishButton);

  Note that I did NOT pass any information about the location of the
  Button! Abbot takes care of all that mess. This is IIRC a big win
  over RobotJ/XDE Tester: no problems with display size, resolution,
  or where stuff ends up on the screen. The only thing you need to do
  @ runtime is make sure that the UI is uncovered: Robot is, like a
  "real user," unable to click on a widget it can't see.

Note that there is a _lot_ more work remaining--we only have fixtures
for a tiny fraction of workbench Resources (e.g. to create projects
with a given nature and containing given artifacts) and scenarios
(e.g. to setup a given configuration of pages)--so we are actively
seeking IBMers (since we're currently only in IIOSB) who would like to
use abbotforswt to automate FVT of their own UIs. We can help you code
the fixtures and testers you will need; in return, we could add your
code to the repository, and help grow the project. If you'd like to
participate, please go to

http://w3.opensource.ibm.com/forum/forum.php?forum_id=999

and say so.

TIA, Tom Roche, WebSphere Studio Model2 Tooling, abbotforswt admin



Back to the top