最近,我为Eclipse扩展点评估引入了一个小助手。 辅助程序努力减少通用编程步骤的样板代码,同时增加开发指导和可读性。
这篇文章是希望的后续文章,展示了如何将实用程序与AssertJ定制断言结合使用,以编写针对Eclipse扩展的轻量级集成测试。
Eclipse扩展
在Eclipse中,松耦合是通过扩展点和扩展机制部分实现的。 因此,扩展充当对特定扩展点的贡献。 但是,扩展名和扩展点的声明性有时会导致出现问题,可能很难跟踪。
如果偶然删除了扩展声明,使用参数扩展了可执行扩展的默认构造函数,未将plugin.xml
添加到build.properties
可能是这种情况。
取决于PDE错误/警告设置,应该通过标记将许多此类问题告知他人,但是由于某种原因,它会一次又一次地发生,导致无法识别贡献,并且由于错误跟踪而浪费了宝贵的时间。
因此,进行轻量级集成测试以验证是否确实可以使用某个贡献可能会有所帮助。
有关如何使用扩展点机制扩展Eclipse的一般信息,您可以参考在线文档的《 插件开发环境指南 》。
与JUnit插件测试的集成测试
给定最后一个帖子的扩展点定义...
…扩展贡献可能看起来像这样:
<extensionpoint="com.codeaffine.post.contribution"><contributionid="myContribution"class="com.codeaffine.post.MyContribution"></contribution></extension>
假设我们具有“使用片段测试插件”中所述的测试片段 ,我们可以引入PDETest来验证上面具有给定id的扩展是否存在并且可以由默认构造函数实例化。 此测试利用了上一篇文章介绍的RegistryAdapter
和称为ExtensionAssert
的特定自定义断言:
public class MyContributionPDETest {@Testpublic 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 );}
}
如前一篇文章所述, RegistryAdapter#readExtension(String)
精确读取给定“ id”属性的一个扩展名。 如果它使用此属性检测到多个贡献,则将引发异常。
ExtensionAssert#assertThat(Extension)
(通过静态导入使用)提供了一个AssertJ自定义断言,该断言提供了一些对扩展贡献的常见检查。 该示例验证了'class'属性的值与该贡献的实现类型的完全限定名称匹配,该可执行扩展实际上可以使用默认构造函数实例化,并且该实例可分配给Runnable
。
在哪里得到的?
对于那些想要签出的人,有一个P2存储库,其中包含com.codeaffine.eclipse.core.runtime和com.codeaffine.eclipse.core.runtime.test.util功能, 其中提供RegistryAdapter
和ExtensionAssert
。 该存储库位于:
- http://fappel.github.io/xiliary/
源代码和问题跟踪器托管在:
- https://github.com/fappel/xiliary
尽管目前完全没有文档,但是应该很容易从本文和上一篇文章的说明开始。 但是请记住,这些功能还处于早期状态,可能会发生一些API更改。 特别是,嵌套扩展的断言目前似乎太弱了。
如果您有改进的想法或发现了一些错误,则问题跟踪器可能是处理此问题的最佳位置,其他任何地方都可以使用下面的评论部分。
翻译自: https://www.javacodegeeks.com/2014/11/lightweight-integration-tests-for-eclipse-extensions.html