• a test framework, test APIs, which read like a GUI test specification
• the ability to automate the testing of blocking UI elements, namely wizards and dialogs

The first was easy, I took a couple of our WSDL-to-Java project wizard GUI test cases and prototyped the kind of APIs I wanted, they read just like we write our test specs. Then I implemented the APIs, most of which were very thin (but more test friendly) facades on existing APIs and existing test code. That left me with the wizards and dialog problem. When you launch an SWT wizard or dialog from a PDE junit test, it blocks because its waiting on input from the SWT event queue. The blocking happens in the open() method of org.eclipse.jface.window.Window, from which WizardDialog is derived. In an automated test, we want the input to come from the junit test code, not from the SWT event queue. Fortunatly, open() is public. I will resist going off on a tangent here about one of my pet gripes: the excessive marking of methods as private and classes as final etc. – let me decide how I want to specialise your code, you cannot see all ends and mostly I know what I’m doing. Anyway, back on topic, so now we have our own CcWizardDialog (which extends WizardDialog), and the code looks like this:

public int open() {
  if (this.cctest == null) {
    return super.open();
  }
  else {
    return doTestOpen();
  }
}
protected int doTestOpen() {
  Shell shell = getShell();
  if (shell == null || shell.isDisposed()) {
    shell = null;
    create();
  }
  shell = getShell();
  constrainShellSize();
  shell.open();
  ICcWizard ccWizard = new CcWizardImpl(getWizard(), this);
  cctest.testWizard(ccWizard);
  return getReturnCode();
}

The cctest member is an object that implements a simple callback interface, typically its the junit test itself. There is no difference in adding these kinds of test hooks to code and doing test-driven development. We write our code to be testable by code. Remember that we’re not trying to test SWT or core Eclipse platform components, we know they are well covered, stable, mature – basically: we know they work. And of course we do manually test and use our tools too. The ICcWizard interface looks like this:

public interface ICcWizard {
  ICcWizardPage getCurrentPage();
  ICcWizardPage next();
  ICcWizardPage back();
  void finish();
  void cancel();
  IWizard getWizard();
  boolean isNextEnabled();
  boolean isFinishEnabled();
}

And (an abbreviated) ICcWizardPage interface looks like this:

public interface ICcWizardPage {
  void setTextValue(...);
  void selectComboValue(...);
  void setCheckBox(...);
  void setRadioButton(...);
  ...
}

Now you can start to see how the junit test reads, just like you’d write a GUI test spec: launch the wizard, set a value in a text box, select a value in a combobox, go to the next page in the wizard, select a radio button, press finish. After which the call stack unwinds back to the junit test, which can then use project APIs to verify the results. I’ve been deliberately vague about ICcWizardPage. How that works is also quite interesting, and very simple. I will detail this and more in another posting. What I really like about the whole approach is that the tests are quick to write and simple to maintain.

Our core model is described in XML Schema and we generate our EMF model from that. A few points then:

• This is an excellent getting started presentation.
• It can seem like there is a huge gap between an initially generated editor (based on your model/schema) and where you know it needs to be. There may well be, but it is not necessarily a code-gap. The temptation is to jump in and start extending and modifying generated code, patience is required to do the right thing. Doing the right thing means trawling through examples and forums, posting questions to newsgroups and waiting on answers.
• Go back to your source schema, modify and constrain it appropriately to help get the end feature the way you want in the generated editor.
• If you have a schema that contains a lot of similar things, start with a subset of the schema which contains just one example of all the distinct elements, and get a working editor for that. Then add back in the other stuff – which is hopefully just repetition. In other words, reduce the problem space to something manageable to start with.
• Make one model change then re-generate. The error reporting in the generation process is not very clear and diagnosing one cause and effect at once is by far the easiest way to work. Read all the error information reported and watch for compilation errors in the generated code too.
• Make small changes to the model, regenerate and test them. When you are happy, commit those distinct changes to source control. Move on to the next task.
• Keep step-by-step instructions for regenerating your EMF and GMF models when your schema changes, there will probably be a few manual fix-ups required (e.g. GMF 1.x doesn’t merge plugin.xml changes – 2.0 does apparently)

GMF has made it possible for us to have a great graphical editor for our Assemblies in a timeframe we would not have been able to GEF-code one in – or at least, nothing this polished and (almost) ready to ship! Hats off to the folks behind it.