Lightweight Integration Tests for Eclipse Extensions
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.
Testing with JUnit
Testing with JUnit is one of the most valuable skills a Java developer can learn. No matter what your specific background, whether you’re simply interested in building up a safety net to reduce regressions of your desktop application or in improving your server-side reliability based on robust and reusable components, unit testing is the way to go.
Frank has written a book that gives a profound entry point in the essentials of testing with JUnit and prepares you for test-related daily work challenges.
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.
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
https://fappel.github.io/xiliary/
and the source code and issue tracker is hosted at
https://github.com/fappel/xiliary
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.
Title Image: © Depositphotos.com/MyVector
With a specialization in the Java language and a keen focus on quality-oriented agile methodologies, he is a strong advocate for test-driven practices.
To Frank, the software development process is akin to craftsmanship, founded on a harmonious blend of knowledge and daily work experience.
fappel@codeaffine.com
- Xmas Clean Sheet Update (0.9) - 21. December 2021
- Clean Sheet Service Update (0.8) - 23. May 2020
- Clean Sheet Service Update (0.7) - 24. April 2020