Writing tests for SWT based UIs often requires to notify widget listeners programmatically. Unfortunately the code to create, initialize and finally to trigger the event is a bit verbose and distracts from the actual purpose of the test. After writing similar initialization routines a couple of times I came up with a little utility class that avoid these redundancies and make the code somewhat more expressive¹

The class is called SWTEventHelper and uses a fluent interface coding style combined with static imports² as known for example from Mockito. The following snippets demonstrate the usage by a simple example:
 
 

public class MouseDownCounter extends MouseAdapter {

 private int count;

 public MouseDownCounter( Control control ) {
 control.addMouseListener( this );
 }

 @Override
 public void mouseDown( MouseEvent event ) {
 count++;
 }

 public int getCount() {
 return count;
 }
}

Looking at the code of the MouseDownCounter one may consider it necessary to ensure that a mouse down event actually increases the count by one. With the SWTEventHelper a test to do so could look like this:

public class MouseDownCounterTest {

 @Rule
 public final DisplayHelper displayHelper = new DisplayHelper();

 @Test
 public void testMouseDownIncreasesCount() {
 Composite parent = displayHelper.createShell();
 Control control = new Label( parent, SWT.NONE );
 MouseDownCounter counter = new MouseDownCounter( control );

 trigger( SWT.MouseDown ).on( control );

 assertEquals( 1, counter.getCount() );
 }

 [...]
}

The test creates a ‘real’ SWT control³ in the build⁴ section of the test. After that the control is ‘wrapped’ by our unit under test, the MouseDownCounter. The following operate section creates a SWT.MouseDown Event using SWTEventHelper#trigger(int) and the listener that got registered at the Label control is notified via SWTEventHelper#on(Widget). Last but not least the check section ensures that the mouse down has actually increased the counter.

The SWTEventHelper furthermore provides a configuration method for each attribute of org.eclipse.swt.widgets.Event. Look at the following line of code to see how to fire an event notification with e.g. a certain Event#keyCode:

trigger( SWT.MouseDown ).withKeyCode( SWT.BUTTON1 ).on( control );

As I have used this little helper for over a hundred times now it might be useful for others too. Hence I set up a GitHub gist where you can download the SWTEventHelper code: https://gist.github.com/fappel/9426554

Don’t be shy, give it a try!

1. Expressiveness is of course, at least to some extend, in the eye of the beholder
2. Eclipse offers the possibility to configure content assist with static imports via the favorites preference settings which makes this approach even more comfortable
3. The DisplayHelper reduces typing effort by handling Display related initialization and disposal automatically. You can find a description and a download link in the post A JUnit Rule to Ease SWT Test Setup
4. The test formatting is based on the BUILD-OPERATE-CHECK pattern (Robert C. Martin, Clean Code, Chapter 9, Clean Tests). However in a real world scenario I would probably extract the build section into a separate method