By Adrian Mouat, EPCC.

Testing Eclipse plug-ins isn’t the straightforward walk-in-the-park you might be hoping for. For me, it’s been a marathon in a maze full of dead-ends. In the hope that I can spare you some of my pain, here are ten hints for anyone embarking on a similar journey:

1. As you probably know, you can use Run As to run code as a JUnit Plug-in Test. This creates a new workbench instance for running the tests, which means you can use the Eclipse Platform API within your tests. You have a large degree of control over the launched workbench, including options to control exactly which plug-ins are in the workbench or to run headless. (This run method is frequently referred to as PDE JUnit Testing if you want to search for further resources.)
2. Further to the idea of controlling the test workbench, be aware of the concept of a Target Platform – this allows you set up a workbench for compiling and testing against that is significantly different to your host workbench.
3. Put any PDE JUnit test code in a completely separate plug-in. This sounds like a pain, because it creates yet another project in your workspace, but it is necessary to avoid your released plug-in being dependent on JUnit or other test resources. (You might need to export extra packages from the plug-in under test before they can be used in the tests. I’m not aware of a way round this problem.)
4. If it is possible to separate your plug-in code into separate model and view plug-ins (or perhaps a jar and a plug-in) - seriously consider doing so. This means that your model tests can be completely separate from your view tests, so that changes to ephemeral things like dialogue boxes won’t break the tests.
5. You might find that you can use mocking libraries to isolate your code and avoid depending on components which require user interaction. Or you may well find this is far more trouble than it’s worth. (I started down this path but gave up when a supertype asked for user-confirmation with no way to turn it off.)
6. PDE JUnit tests are naturally pretty slow because they need to start and stop Eclipse. This a major problem, because it makes you less willing to run the tests and increases the time needed to write them (you could argue that they are no longer truly unit tests). You might be able to overcome this problem by using a continuous test runner, which will regularly run the tests for you in the background.
7. You might find SWTBot to be a lifesaver. It provides various methods for locating user interface (UI) elements and exercising them. For example, you might ask it to find the dialog box which says Confirm Delete and click the button titled Yes. There are also controls for waiting on various conditions and taking screenshots of failures. There is also SWTGefBot, which has special features for getting GEF elements. Be warned that SWTBot has a typical lack of documentation and several outstanding bugs. (I just noticed a similar UI testing tool called WindowTester Pro which looks like it might be a better choice).
8. Be aware of whether or not your tests run in the UI thread: SWTBot tests never do, but PDE JUnit tests will by default. If you are not in the UI thread, you will have to use the syncExec or asyncExec methods (either from the Eclipse Display class or the SWTBot UIThreadRunnable class) to run any code that calls the PlatformUI in Eclipse. If you do run in the UI thread, be aware that your test will hang if the editor waits for a user response.
9. Documentation on how to do plug-in testing is sparse. Some of the best resources are the tests for existing plug-ins – I’ve been looking at the tests for Graphiti, which use a range of techniques including mocking and SWTBot. If you’re using SWTBot, you will probably need to look at the source code to figure out how to use it in some cases.
10. Have a look at buckminster, a framework for automating building, testing and deploying Eclipse-based software solutions. It looks like it supports PDE JUnit Tests and SWTBot and could potentially be used for setting up a continuous-integration-style build/check-in process. I only recently came across this, so I haven’t had time to try it out.

This post was originally published in the OGSA-DAI blog.