Recently I introduced a little helper for Eclipse extension point evaluation. The auxiliary strives to reduce boilerplate code for common programming steps, while increasing development guidance and readability at the same time.
This post is the promised follow-up that shows how to combine the utility with an AssertJ custom assert to write lightweight integration tests for Eclipse extensions.
Eclipse Extensions
Loose coupling is in Eclipse partially achieved by the mechanism of extension-points and extensions. Whereby an extension serves as a contribution to a particular extension-point. However the declarative nature of extensions and extension-points leads sometimes to problems, which can be difficult to trace.
This may be the case if by accident the extension declaration has been removed, the default constructor of an executable extension has been expanded with parameters, the plugin.xml has not been added to the build.properties or the like.
Depending on the PDE Error/Warning settings one should be informed about a lot of these problems by markers, but somehow it happens again and again that contributions are not recognized and valuable time gets lost with error tracking.
Because of this it might be helpful to have lightweight integration tests in place to verify that a certain contribution actually is available.
For general information on how to extend Eclipse using the extension point mechanism you might refer to the Plug-in Development Environment Guide of the online documentation.
Integration tests with JUnit Plug-in Tests
Given the extension-point definition of the last post…
… an extension contribution could look like this:
<extension
point="com.codeaffine.post.contribution">
<contribution
id="myContribution"
class="com.codeaffine.post.MyContribution">
</contribution>
</extension>Assuming that we have a test-fragment as described in Testing Plug-ins with Fragments, we could introduce a PDETest to verify that the extension above with the given id exists and is instantiable by a default constructor. This test makes use of the RegistryAdapter introduced by the previous post and a specific custom assert called ExtensionAssert:
public class MyContributionPDETest {
@Test
public void testExtension() {
Extension actual = new RegistryAdapter()
.readExtension( "com.codeaffine.post.contribution" )
.thatMatches( attribute( "id", "myContribution" ) )
.process();
assertThat( actual )
.hasAttributeValue( "class", MyContribution.class.getName() )
.isInstantiable( Runnable.class );
}
}As described in the previous post RegistryAdapter#readExtension(String) reads exactly one extension for the given ‘id’ attribute. In case it detects more than one contribution with this attribute, an exception would be thrown.
ExtensionAssert#assertThat(Extension) (used via static import) provides an AssertJ custom assert that provides some common checks for extension contributions. The example verifies that the value of the ‘class’ attribute matches the fully qualified name of the contribution’s implementation type, that the executable extension is actually instantiable using the default constructor and that the instance is assignable to Runnable.
Where to get it?
For those who want to check it out, there is a P2 repository that contains the features com.codeaffine.eclipse.core.runtime and com.codeaffine.eclipse.core.runtime.test.util providing the RegistryAdapter and the ExtensionAssert. The repository is located at:
and the source code and issue tracker is hosted at:
Although documentation is missing completely at this moment, it should be quite easy to get started with the given explanations of this and the previous post. But keep in mind that the features are in a very early state and probably will undergo some API changes. In particular assertions of nested extensions seems a bit too weak at the moment.
In case you have ideas for improvement or find some bugs the issue tracker is probably the best place to handle this, for everything else feel free to use the comment section below.
| Reference: | Lightweight Integration Tests for Eclipse Extensions from our JCG partner Frank Appel at the Code Affine blog. |
