Testing a Plug-in - an introduction

We all know, we should test our code... and if at all possible, we should write regression tests for the code as well. Just so we can make sure the functionality isn't broken as we add to the code or change the target platform. (And, of cause to make sure that we agree with the customer about the intended functionality of our code, right?)

This is even more relevant for Eclipse plug-in development. Especially since the Eclipse platform provides some very fancy - and sometimes complex - interfaces that can perform all sorts of stuff. One area of Eclipse plug-ins that really requires a special focus when testing is the use of configuration files (most notably MANIFEST.MF and plugin.xml) to specify major parts of the functionality. Here your usual junit tests require some refinements...

It is not because I just love to test... But the last 25 years as a developer have shown me time and time again that I spend more time doing fun stuff if I write a regression test the first time. As I spend all my time writing Eclipse plug-ins, this means that I have developed a large number of techniques for testing different aspects of a plug-in. Some of these are rather trivial while others have taken me a long time to get right.

I have found myself using a lot time on some specific tests... sometimes it is a bit of an intellectual challenge to test something right. This is especially true when you have to fix an odd problem from a customer and want to make sure the problem stay fixed.

As a consultant in everything Eclipse, I'm often asked about best practices for testing Eclipse based applications. Not that I can claim to know the best practices, but in the next couple of weeks, I intend to write a series of post about how I test specific aspects of a plug-in. These posts will focus on the main aspects of a plug-in as I see them.

• MANIFEST.MF
• User Interface
• Everything that connects plugin.xml with the rest of the plug-in
• Commands and Handlers
• Expressions
• Source Providers
• Views and Editors
• ...and the functionality provided by the plug-in itself

Consider these posts my best answer for the best practices.

There are still room for improvements in my testing techniques and I hope that any readers will take the time to point me towards other techniques or tricks that might be relevant. Especially if this means, it is easier to test or if we can get a better coverage of potential problems.

At EclipseCon...

At EclipseCon, I will present some of these techniques in a talk Wednesday just after lunch - though in 20 minutes, we will just have time to touch of the different techniques and not go into any sort of details.