1. You have a bug.

2. The bug is hardly reproducible, but when reproduced it appears to be very serious.

3. There are a number of teams involved in the functionality where the bug is found.

As a result what actually happens in most of the cases is “ping pong”. This bug is constantly moved from one owner to another and vice versa. Nobody really wants to spend a decent amount of resource to investigate and resolve this issue. And even if someone do, the problem might require the right person for the job which is actually difficult to achieve. And this can continue for years. From one version to another where surrounding code is constantly changing and evolving which makes it even harder to investigate. And if you have an extensible environment as Eclipse, where one user can have a completely different set of plug-ins from another, the task is nearly impossible.

Last week I came to such a problem.

1. A file in the workspace could not be deleted.

2. The bug was first reported 2 years ago and a number of times after that, but it could never be reproduced.

3. More then 5 teams have code that is “processing” this file.  Teams were constantly changing and evolving for the last 2 years so even the knowhow is not concentrated.

If a file can not be deleted there must be a handle open for this file. It took us about 2 minutes to download JPicus from the update site and create a snapshot of open handles and failed delete operations in the installation where the problem was reproduced.

There was a failed delete operation for a file and JPicus shows 5 handles for this file one of which is “still open”.

Selecting the handle you can see the stack trace of opening the handle in Thread View.

Having the stack trace and delegating to the right team an hour later the bug is investigated and a solution is pending.

As mentioned here:

Monday - I have created a google alert for “eclipse”

Tuesday evening - 9 Alerts for “eclipse”

Wednesday evening - 34 Alerts for “eclipse”

Thursday evening - 42 Alerts for “eclipse”. And it seems dev.eclipse.org is kind of slow. Probably people are busy downloading Galileo instead of blogging

BTW: Did you know that the Sun and the moon are also having a simultaneous release this summer? Release candidate is on July 7 with with a lunar eclipse on. We can expect the simultaneous release on July 22 with a solar eclipse. There should also be a Service Release 1 - lunar eclipse on August 7. Hope you can witness it since from Bulgaria it will be difficult…

In Thuesday evening I have received about 9 results from Google.

Today - just a few hours after Galileo my google mail is filled with 34 sumarazide alerts about eclipse.

Of course it is difficult to even sort them in a decent time. But I am sure all of them are connected with Eclipse Galileo…

It is interesting to see how will this trend evolve till the end of the week.

Wizads have always been a subject of low code coverage and no unit testing. Many examples could be given were the whole test suite of a project is green, but when a user starts using the product there are an enormous number of errors. And generally the user starts with the wizards…

As everything in JPicus the NewConnectionWizard is 100% covered with test.

This are coverage results from unit testing the wizard package:

This are coverage results from integration testing* the wizard package:

Combined the result is 100%

*With “integration test” I mean a JUnit test that includes creating of more then 3 (inclusive) productive code objects. A test that verifies the correct integration between objects, but only the tiny little places of integration. Integration tests are something written and executed by the developer.

First - the provided functionality:

The NewConnectionWizard allows a user to create a new connection to a JPicus agent. There is only one page where a host and port are entered. If the port is not valid the page should show an error message. If there is no such host an error dialog should be shown when pressing Finish. When the user presses Finish a new connection should be created and shown in the AgentConnectionsView.

Second - from an eclipse developer point of view we have:

Instances of IWizard and IWizardPage. The wizard page contains a Composite with two Labels and two Text fields. A ModifyListener is responsible for handling modification of the host and port text fields.

Third - the Tests:

The first thing about wizard pages is that there should be no business logic in the wizard page. Create a “controller” and put all this logic in it. In this case the HostAndPortPageController. Create an interface for this controller and inject it in the wizard page. I recommend passing the controller as an argument to the constructor of the page. And there is no default constructor. The page can not leave without its controller. Do not leave the page to create the controller by itself. Invert the dependency (DIP).

public HostAndPortWizardPage(IHostAndPortPageController controller) {
super(CONNECTION_PROPERTIES);
setDescription(Messages.HostAndPortWizardPage_specifyHostAndPort);
setTitle(CONNECTION_PROPERTIES);
setImageDescriptor(JPicusUI.getImageDescriptorForPath(”icons/pecker64.png”));
this.controller = controller;
}

Creating a controller for every page might seem tedious at first. But it will pay off. And if you are have a dependency to Web Tools Platform then using the Data Model Wizards framework is more then appropriate.

Since there is no business logic in the wizard what should be tested?

Is there a SWT control of the page and is this control actually a child of the passed shell? (Here createControl() creates a new HostAndPortWizardPage, calls page.createControl(shell) and returns the page).

@Test
public void testGetControl() {
IWizardPage page = createControl();
assertEquals(1, shell.getChildren().length);
assertSame(shell.getChildren()[0], page.getControl());
}

Are the correct children of the control created?

@Test
public void testControlChildren() {
Composite composite = getControl();
assertEquals(4, composite.getChildren().length);
assertEquals(Label.class, getHostLabel(composite).getClass());
assertEquals(Text.class, getHostText(composite).getClass());
assertEquals(Label.class, composite.getChildren()[2].getClass());
assertEquals(Text.class, getPortText(composite).getClass());
}

Is the layout of the wizard correct? (Do not test whether the layout is working. It is a SWT layout so it is working. Test only that the correct layout with the correct properties is set to the composite).

@Test
public void testControlLayout() {
Composite composite = getControl();
GridLayout layout = (GridLayout) composite.getLayout();
assertEquals(2, layout.numColumns);
assertFalse(layout.makeColumnsEqualWidth);
}

Are the correct checks made when modifying a text field?

@Test
public void testModifyPortNotANumber() {
expect(controller.checkPort(”not a number”)).andReturn(”error message”);
// test
IWizardPage page = createControl();
Text port = getPortText((Composite) shell.getChildren()[0]);
port.setText(”not a number”);
assertEquals(21500, ((HostAndPortWizardPage) page).getPort());
assertEquals(”error message”, page.getErrorMessage());
}

The left of the wizard page implementation is mostly interacting with the controller. Since the controller is represented by an interface it allows for a good abstraction of the details. Having a good mock library (in my case easymock) testing the wizard page and reaching 100% coverage, with meaningful tests*, is straightforward.

*With meaningful tests I refer to the rule to write tests that will break when a productive code is change. Writing tests for the purpose of only reaching a good code coverage is useless and dangerous.

I have heard comments that this wizard page is very simple and that`s way it could be unit tested, but if a wizard page is too complicated to be unit tested isn`t it too complicated for the user to use?

As a result - wizard pages can be tested. In Eclipse it has always been this way…

How are your wizard pages tested?

Similar to every view in JPicus, the AgentConnections view is 100% covered with unit tests. This view specifically has 95.9% (71 lines) covered with unit test and 12.1 % (9 lines) covered with an integration test.

First - the provided functionality:

The AgentConnections view allows the user to create a new connection to a JPicus agent. It can maintain more then one connection. For every connection the user can create a number of Snapshots (using the Take Snapshot action). Double click on the snapshot opens another view. There is also a context menu on every snapshot. Selecting the snapshot will give you the snapshot properties in the properties view.

Second - from an eclipse developer point of view we have:

TreeViewer, two actions in the view tool bar, context menu, double click listener (and action for the listener) and finally a selection provider.

Third - the Tests:

Unit testing the content and label provider is pretty straightforward and very domain specific. Testing the actions also - there are the IAction and IActionDelegate interfaces that allow for pretty well decoupling. But how do you test the view?

As every object the AgentConnections view has

• an input - the connections and snapshots to be shown (IConnectionsHolder)
• an output - the output is actually the viewer
• a helper - IActionFactory that helps decoupling the creation of actions from their use
• an error handler - in this case org.eclipse.core.runtime.ILog

In order to unit test the view you must inject the input,helper,error handler (preferably in the constructor). Do not leave the view to create this things by it self. Invert the dependency (DIP).

public AgentConnectionsView(IConnectionsHolder connections, IActionFactory actionFactory, ILog log) {
this.connections = connections;
this.log = log;
this.actionFactory = actionFactory;
}

Of course since this is a view it is registered in the plugin.xml. And it must have a default constructor. This could be implemented in a similar way and tested with an integration test:

public AgentConnectionsView() {
this(JPicusUI.getDefault().getConnectionsHolder(), new ActionFactory(),  JPicusUI.getDefault().getLog());
}

Since every ViewPart is an WorkbenchPart it delegates its getAdapter(Class) method to Platform.getAdapterManager().getAdapter(this, adapter). This is the other method where you can not get away from the integration test.

All the other methods of a view can (and should) be unit tested. Having a good mock library (in my case easymock) you can easily mock IConnectionHolders, IActionFactory, ILog, IViewSite, IWorkbench etc. Since the IViewSite contains IActionBars, IToolBarManager, IMenuManager it is also straightforward to test that the correct actions are added to the tool bar.

The most challenging methods from AgentConnectionsView are createPartControl() and setFocus().

createPartControl(Composite)

Call this method in the following way in you tests.

Display.getDefault();
Shell shell = new Shell(Display.getDefault());
view.init(site);
view.createPartControl(shell);

And verify that the shell actually has some children (it this case a Tree). Although this involves creating a shell it won`t block your thread.

setFocus()

Given the following implementation of setFocus()

public void setFocus() {
viewer.getControl().setFocus();
}

implementing a unit test is more challenging. Fortunately there is a Control.addFocusListener(FocusListener)  method. Using the FocusListener the test could be

public boolean verifySetViewFocus(IViewPart view)  {
final boolean focus[] = new boolean[1];
focus[0] = false;
getViewer().getControl().addFocusListener(new FocusAdapter() {
public void focusGained(FocusEvent e) {
focus[0] = true;
}
});
view.setFocus();
// on Linux the focus listener is notified after the test completes. So
// start a new runnable that will wait for a little.
ModalContext.run(new IRunnableWithProgress() {
@Override
public void run(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
Thread.sleep(1);
}
}, true, new NullProgressMonitor(), Display.getDefault());
assertTrue(focus[0]);
}

As a result - the user interface can be tested. In Eclipse it has always been this way…

I heard this quote just a few weeks ago. Do not know whether it is really Mark Twain that said it, but it is an interesting quote.

This is one of the “jokes” a friend of mine used in his presentation at JavaOne 2009. More specifically Technical Session TS-4588 which is all about analysing your I/O.

Have you ever wondered

• How much I/O does my program use?
• How much time is spent in I/O?
• Hot spots. What can be improved?
• Which handles are currently open?
• Where was a handle opened and closed?
• Why did a delete operation fail?
• Where and when was this file deleted?
• Was there some interference from external processes?

Well Pavel (my friend I have mentioned) has definitely wondered. A few months ago he came to me with a question whether I could assist him in implementing such a tool. A tool that will give us all these answers.
Generally my part was to implement the integration with Eclipse. A few views, a wizard, some actions, a nice perspective. And - this is the result

If you think such a tool could assist you visit JPicus home page.
It is still only free. But we are working on making it open

And there is more on JPicus coming in the near future.