Automatic test suites in Usus 0.6

For those of you who were at the Eclipse Testing Day, listening to the talk Marc and I gave about test suites in the Eclipse IDE: the new Usus feature we described is now released. It's part of Usus 0.6. If you already have Usus 0.6, you can install it separately from the Usus update site at http://projectusus.googlecode.com/svn/updates.

Here's what it does:

Just as you can simply right-click any Java project in the workspace and run all JUnit tests contained in it, you can now select any two or more projects and run all their tests as well. The only condition is that there is at least one project somewhere in the workspace that is a common dependency root of both (or all) selected projects, i.e. a project that depends, directly or indirectly, on both (or all of them). There is normally at least one such project, namely the one where you'd put your AllTests suite. Only of course with this new feature in Usus, you don't need an AllTests suite any more :-)

(A couple of remarks: If you select two projects where one of them depends on the other,  directly or indirectly, there is no need for an additional project that acts as common dependency root. The depending project itself can play this role.

A Java project in the workspace 'depends' on another project when it has that project on its Java Build Path, as a required project. Among other things, this includes plug-in projects that are declared as required plug-ins when you do Eclipse plug-in development. Thus, if you do plug-in development, you can use this feature on any two plug-in projects as long as they are in the same dependency tree.)

There's a second interesting new thing you can do with JUnit test suites in Usus 0.6. You can also select a single Java project, and choose Run As... All Tests Suite (JUnit). Usus will then collect all JUnit tests in that project and all its dependencies, i.e. walk the entire dependency tree
and create a test suite from all tests found.

Speaking at the Eclipse Testing Day

My colleage at andrena, and fellow blogger over at Crafting Code, Marc and I will give a talk at the Eclipse Testing Day in Darmstadt on Sep 8th. Here's the abstract:

In software projects with sizeable code bases maintaining the suite of all unit tests regularly becomes an issue: developers want to be able to execute the entire collection of tests with a single command, but an AllTests suite that lists the test cases explicitly must be kept manually, which is inefficient and error-prone.
The well-known ClasspathSuite solves this problem elegantly, but it has its weaknesses, too: it becomes slow on large workspaces and executes static code blocks in all classes when loading and analyzing them, which can cause unexpected effects and in some cases make the tests fail.
The Eclipse IDE allows to run all tests in a single Java project or source folder directly from the context menu, but doesn't extend this functionality to the entire workspace. (For good reasons, as we will explain in the talk.) There are approaches to mitigate this issue (e.g. this Plug-in), but they have their own shortcomings. Still, they clearly show the need for a solution in this area.
After discussing the current status of test suite management in Eclipse, we introduce a new approach to address these issues; we'll also demonstrate a prototypical implementation which we are currently developing at Project Usus.

 (If you want to join us at the Testing Day, here's the registration link :-)

How to code with a hedge trimmer

Something you do often in an Eclipse RCP application (because it's a client in some client-server-architecture) is to access a server and do something with a model object.

For instance, you may have a table view that shows a list of customers, represented by objects of type Customer. (Ok, I know it's a lame example.You're invited to use your imagination, if you'd like to see something more colorful ;-)

One of the tasks then is to load all customers from the server and put them as input on the table view. Thus your code would look something like this:

  CustomerService service = getCustomerService();
  List<Customer> customers = service.loadAllCustomers();
  customersTableViewer.setInput( customers );

Code growing out of proportion... 

Of course, it's never quite that easy. Normally, a service call is a long-running operation, so the least you can do is to show a busy indicator to the user. But that requires that you put your code in a Runnable:

  class LoadAllCustomers implements Runnable {
  
    private List<Customer> serverAccessResult;
  
    @Override
    public void run() {
      CustomerService service = getCustomerService();
      serverAccessResult = service.loadAllCustomers();
    }
    
    List<Customer> getServerAccessResult() {
      return serverAccessResult;
    }
  }

and then you can say:

  LoadAllCustomers op = new LoadAllCustomers();
  BusyIndicator.showWhile( op );
  customersTableViewer.setInput( op.getServerAccessResult() );

(Of course, you could do that in an anonymous implementation of Runnable, but bear with me for a moment, you'll see I've used a slightly more elaborate way for didactic reasons ;-)

Sometimes, however, you may expect the server call to run even longer, and therefore you want to shift it into the background entirely, so that the user can continue working until the server access results have arrived:

  class LoadAllCustomers extends Job {
  
    private List<Customer> serverAccessResult;
  
    LoadAllCustomers() {
      super( "Loading customer data" );
    }
  
    @Override
    public IStatus run( IProgressMonitor monitor ) {
      CustomerService service = getCustomerService();
      serverAccessResult = service.loadAllCustomers();
      return Status.OK_STATUS;
    }
    
    List<Customer> getServerAccessResult() {
      return serverAccessResult;
    }
  }

and then:

  Job job = new LoadAllCustomers();
  job.schedule();

... ah, just a second. What now? We could wait for the job to finish by calling join(), but what use would that be? That would destroy the point of putting something into a background job, wouldn't it? So we need a job-changed listener here:

  LoadAllCustomers op = new LoadAllCustomers();
  op.addJobChangeListener( new JobChangeAdapter() {
    @Override
    public void done( IJobChangeEvent event ) {
      LoadAllCustomers loaderJob = ( LoadAllCustomers )event.getJob();
      customersTableViewer.setInput( loaderJob.getServerAccessResult() );
    }
  } );
  op.schedule();

Looks good? No, still no joy: this listener will be called from a thread outside the UI thread, and this will cause an invalid thread access. So this is getting more complicated-looking by the minute:

  LoadAllCustomers op = new LoadAllCustomers();
  op.addJobChangeListener( new IJobChangeListener() {
    @Override
    public void done( IJobChangeEvent event ) {
      LoadAllCustomers loaderJob = ( LoadAllCustomers )event.getJob();
      Display.getDefault().asyncExec( new Runnable() {
        @Override
        public void run() {
          customersTableViewer.setInput( loaderJob.getServerAccessResult() );
        }
      } );
    }
  } );
  op.schedule();

(Of course, not to mention any error handling you also might want to do.)

To summarize: you basically have the same one or two lines of code, but you sometimes need them as a Runnable, sometimes you need them as a Job, and you may or may not have to put the follow-up operation in the UI thread.

... and cutting it back

Here's how I like to organize this a little.

First step: put the server access code for loading all customers and the follow-up code in their own classes.

  class LoadAllCustomers extends Job implements Runnable {
  
    private List<Customer> serverAccessResult;

    LoadAllCustomers() {
      super( "Loading customer data" );
    }
  
    @Override
    public IStatus run( IProgressMonitor monitor ) {
      run(); 
      return Status.OK_STATUS;
    }
  
    @Override
    public void run() {
      CustomerService service = getCustomerService();
      serverAccessResult = service.loadAllCustomers();
    }
    
    List getServerAccessResult() {
      return serverAccessResult;
    }
  }

  
  class SetInputAfterJobDone extends JobChangeAdapter {

    private final Viewer viewer;
    
    SetInputAfterJobDone( Viewer viewer ) {
      this.viewer = viewer;
    }
  
    @Override
    public void done( IJobChangeEvent event ) {
      LoadAllCustomers loaderJob = ( LoadAllCustomers )event.getJob();
      setInputInUIThread( loaderJob.getServerAccessResult() );
    }

    private void setInputInUIThread( Object input ) {
      Display.getDefault().asyncExec( new Runnable() {
        @Override
        public void run() {
          viewer.setInput( input );
        }
      } );
    }  
  }

(You can see now what I meant by 'didactic reason' a few lines above.)

You can now use your server access code both as Runnable or as Job:

  LoadAllCustomers op = new LoadAllCustomers();
  BusyIndicator.showWhile( op );
  customersTableViewer.setInput( op.getServerAccessResult() );

  LoadAllCustomers op = new LoadAllCustomers();
  op.addJobChangeListener( new SetInputAfterJobDone( customersTableViewer ) );
  op.schedule();

Second, I generally allow a follow-up behavior, if we're running as a job, by adding this method to LoadAllCustomers:

  public Job andThen( IJobChangeListener followUpBehavior ) {
    addJobChangeListener( followUpBehavior );
    return this;
  }

  So that I can write more compactly:

  new LoadAllCustomers().andThen( new SetInputAfterJobDone( customersTableViewer ) ).schedule();

Finally, pull up some of the common stuff in the server access code, so that you can re-use it for all other sorts of server accesses (like saving customers, querying customer details, and so on):

  public abstract class ServerAccess<T> extends Job implements Runnable {

    private T serverAccessResult;

    public ServerAccess( String name ) {
      super( name );
    }

    @Override
    protected IStatus run( IProgressMonitor monitor ) {
      run();
      return Status.OK_STATUS;
    }

    public T getServerAccessResult() {
      return serverAccessResult;
    }

    public ServerAccess<T> andThen( IJobChangeListener followUpBehavior ) {
      addJobChangeListener( followUpBehavior );
      return this;
    }

    protected void setServerAccessResult( T computationResult ) {
        this.serverAccessResult = computationResult;
    }
  }

Subclasses then merely have to implement the run() method with their own server access logic, and set the result. That should usually be a one-liner, and as you've seen, using these server access objects also normally is. (Correspondingly, generalize SetInputAfterJobDone so that it can cope with ServerAccess objects instead of simple Jobs).

So, here's one exercise left for the interested reader:

  new TryItInYourNext( project ).andThen( new GoAndHaveSome( coffee ) ).schedule();

Tell me how it worked :-)

Keep the bar green to keep the code clean II

Extracting something from a selection

That's a somewhat tedious task in JFace programming: you receive an object that represents the selection on a tree or table viewer; the selection object is of type ISelection (a JFace interface), but that means it could be either an IStructuredSelection (one or more elements from a tree, table or list) or an ITextSelection (some text marked in a text editor); thus you need to check the subtype of ISelection first, then you have to check whether the selection is empty, then you can get the first element (for it might be a multi-selection, too), then you have to cast that into the correct type. All in all, you often end up with something long-winded like this:

selectionService.addPostSelectionListener( new ISelectionListener() {
  public void selectionChanged( IWorkbenchPart part, ISelection selection ) {
    if( selection instanceof IStructuredSelection && !selection.isEmpty() ) {
      IStructuredSelection strusel = (IStructuredSelection)selection;
      Object element = strusel.getFirstElement();
      if( element instanceof MyCoolType ) {
        MyCoolType coolThing = (MyCoolType)element;
        // ... and now we finally can do something with the cool thing
      }
    }
  }
} );

And you think: oh well, shouldn't this be a little easier to do?

You are right to ask that question. Here's one way to do it a little more elegantly:

public void selectionChanged( IWorkbenchPart part, ISelection selection ) {
  MyCoolType coolThing = new ElementFrom( selection ).as( MyCoolType.class );
  // ... now do something with coolThing already
}

And this would be the implementation of the ElementFrom utility:

/** Extract the first element (if any) from a JFace selection, in a type-safe
  * manner.
  */
public class ElementFrom {

  private final ISelection selection;

  /** constructs a new extraction operation.
   *
   * @param selection a JFace selection object from which to extract the
   * selected element. Can be null, in which case this extraction
   * operation yields null.
   */
  public ElementFrom( ISelection selection ) {
    this.selection = selection;
  }

  /** retrieves the extracted element typed as specified.
   *
   * @param cls the class representing the expected type of the extracted element.
   *            Must not be null. 
   * @param  the expected type of the extracted element.
   * @return    the element under the expected type, or null
   */
  public  T as( Class cls ) {
    return extractElement( cls );
  }

  private  T extractElement( Class cls ) {
    T result = null;
    if( selectionIsGood() ) {
      IStructuredSelection strusel = (IStructuredSelection)selection;
      Object element = strusel.getFirstElement();
      if( elementTypeIsGood( element, cls ) ) {
        result = cls.cast( element );
      }
    }
    return result;
  }

  private  boolean elementTypeIsGood( Object element, Class cls ) {
    return cls.isAssignableFrom( element.getClass() );
  }

  private boolean selectionIsGood() {
    return selection instanceof IStructuredSelection && !selection.isEmpty();
  }
}

Have fun :-)

Usus 0.4 preview build available

Just a brief update about what's going on at the Usus front: there is a new preview build of Usus available at projectusus.org — you can get it as usual from the update site (look here for install instructions). This one includes now improved ACD computation and packages in cycles as a new metric.

In other news, today Nicole and Andreas gave a talk about Usus at the 'Eclipse Tools Day' track at JAX 2010, the big Java Enterprise conference in Wiesbaden. If you were there, you've seen the new version first-hand :-)

Ken Schwaber at the Entwicklertag in Karlsruhe, June 21st-25th

There will be quite some highlight at the Entwicklertag this year with Ken Schwaber's keynote, panel discussions and Scrum in Depth course:

http://www.andrena.de/ken-schwaber-kommt

Don't be late to register (and stay tuned, there will be more Entwicklertag news soon :-)