Java 用于 Eclipse 插件开发的自动化单元测试 (junit)

Automating unit tests (junit) for Eclipse Plugin development

提问by rcreswick

I am developing Eclipse plugins, and I need to be able to automate the building and execution of the test suite for each plugin. (Using Junit)

我正在开发 Eclipse 插件，我需要能够为每个插件自动构建和执行测试套件。（使用 Junit）

Test are working within Eclipse, and I can break the plugins into the actual plugin and a fragment plugin for unit testing as described here, hereand in a couple places here.

测试是在Eclipse中工作，并按照上述方法我可以打破插件到实际的插件和片段插件单元测试在这里，这里和在几个地方在这里。

However, each of the approaches above results in the same issue: The java ant task/commandline command that issues the build or should trigger the test, generates no observable side effects, and returns the value "13". I've tried everything I can find, and I've learned a fair bit about how Eclipse starts up (eg: since v3.3 you can no longer use startup.jar -- it doesn't exist -- but you should use org.eclipse.equinox.launcher). Unfortunately, while that is apparently necessary information, it is far from sufficient.

但是，上述每种方法都会导致相同的问题：发出构建或应触发测试的 java ant 任务/命令行命令不会产生可观察到的副作用，并返回值“13”。我已经尝试了我能找到的所有方法，并且对 Eclipse 的启动方式有了一些了解（例如：从 v3.3 开始，您不能再使用 startup.jar——它不存在——但你应该使用org.eclipse.equinox.launcher）。不幸的是，虽然这显然是必要的信息，但还远远不够。

I am working with Eclipse 3.4, Junit 4.3.1 (the org.junit4 bundle, but I would much rather use JUnit 4.4. See here.)

我正在使用 Eclipse 3.4、Junit 4.3.1（org.junit4 包，但我更愿意使用 JUnit 4.4。请参阅此处。）

So, my question is: How exactly do you automate the build and testing of Eclipse plugins?

所以，我的问题是：您究竟如何自动化 Eclipse 插件的构建和测试？

Edit:To clarify, I wantto use something like ant + cruise control, but I can't even get the unit tests to run at alloutside of Eclipse. I say "something like" because there are other technologies that accomplish the same thing, and I am not so picky as to discard a solution that works just because it's using say, Maven or Buckminster, if those technologies make this substantially easier.

编辑：澄清一下，我想使用类似 ant + Cruise Control 的东西，但我什至无法在Eclipse 之外运行单元测试。我说“类似的东西”是因为还有其他技术可以完成同样的事情，而且我不会因为使用 Maven 或巴克明斯特而放弃一个可行的解决方案，如果这些技术使这变得更容易的话。

Edit2:The 'Java Result 13' mentioned above seems to be caused by the inability to find the coretestrunner. From the log:

Edit2：上面提到的'Java Result 13'似乎是由于无法找到coretestrunner造成的。从日志：

java.lang.RuntimeException: Application "org.eclipse.test.coretestapplication" could not be found in the registry. The applications available are: org.eclipse.equinox.app.error, com.rcpquickstart.helloworld.application.
    at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:242)
    at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
    at org.eclipse.core.launcher.Main.main(Main.java:30)

!ENTRY org.eclipse.osgi 2 0 2008-11-04 21:02:10.514
!MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2008-11-04 21:02:10.515
!MESSAGE Bundle update@plugins/org.eclipse.test_3.2.0/ [34] was not resolved.
!SUBENTRY 2 org.eclipse.test 2 0 2008-11-04 21:02:10.516
!MESSAGE Missing required bundle org.apache.ant_0.0.0.
!SUBENTRY 2 org.eclipse.test 2 0 2008-11-04 21:02:10.516
!MESSAGE Missing required bundle org.eclipse.ui.ide.application_0.0.0.
!SUBENTRY 1 org.eclipse.osgi 2 0 2008-11-04 21:02:10.518
!MESSAGE Bundle update@plugins/org.eclipse.ant.optional.junit_3.2.100.jar [60] was not resolved.
!SUBENTRY 2 org.eclipse.ant.optional.junit 2 0 2008-11-04 21:02:10.519
!MESSAGE Missing host org.apache.ant_[1.6.5,2.0.0).
!SUBENTRY 2 org.eclipse.ant.optional.junit 2 0 2008-11-04 21:02:10.519
!MESSAGE Missing required bundle org.eclipse.core.runtime.compatibility_0.0.0.

回答by JesperE

We're using the PDE build scripts (see this question), and we export ant build files for our unit-test plugins. These ant build scripts are then invoked from the PDE build scripts (customTargets.xml) using the "ant" ant-task. Unfortunately, this only works with JUnit3. There's supposed to be a JUnit4-adapter for JUnit3 so you can run JUnit4 tests from a JUnit3 test-runner.

我们正在使用 PDE 构建脚本（请参阅此问题），并为我们的单元测试插件导出 ant 构建文件。然后使用“ant”ant 任务从 PDE 构建脚本 (customTargets.xml) 调用这些 ant 构建脚本。不幸的是，这只适用于 JUnit3。应该有一个用于 JUnit3 的 JUnit4 适配器，因此您可以从 JUnit3 测试运行器运行 JUnit4 测试。

We'll probably move to something like Maven; the PDE build scripts aren't really cut out for what we need to do with them.

我们可能会转向 Maven 之类的东西；PDE 构建脚本并没有真正满足我们对它们的需求。

回答by Fred

Here is a Tool which I can recommand if someone is interrested by TDD : Infinitest

这是一个工具，如果有人对 TDD 感兴趣，我可以推荐它： Infinitest

Short description extracted from the Infinitest site:

摘自 Infinitest 站点的简短描述：

What is Infinitest?

Infinitest is a continuous test runner designed to facilitate Test Driven Development. Infinitest helps you learn TDD by providing feedback as you work, and helps you master TDD by reducing your feedback cycle from minutes to mere seconds.

Whenever you change a class, Infinitest runs your tests for you. It's smart about what tests to run, and only runs the ones you need. If any errors occur, it reports them clearly and concisely. This gives you instant feedback about the semantic correctness of your code, just as modern IDE's give you instant feedback about syntax errors.

什么是无限测试？

Infinitest 是一个连续的测试运行器，旨在促进测试驱动开发。Infinitest 通过在您工作时提供反馈来帮助您学习 TDD，并通过将您的反馈周期从几分钟缩短到几秒钟来帮助您掌握 TDD。

每当您更改课程时，Infinitest 都会为您运行测试。运行哪些测试很聪明，并且只运行您需要的测试。如果发生任何错误，它会清晰简洁地报告它们。这为您提供有关代码语义正确性的即时反馈，就像现代 IDE 为您提供有关语法错误的即时反馈一样。

回答by silverbugg

Use Antand CruiseControl- you call the unit tests in the Antscript as well as the rest of your build logic and can run them with each build iteration - then CruiseControlcan automate your build calls and run these tests each time.

使用Ant和CruiseControl- 您可以在Ant脚本中调用单元测试以及构建逻辑的其余部分，并且可以在每次构建迭代时运行它们 - 然后CruiseControl可以自动执行构建调用并每次运行这些测试。

回答by jamesh

I have just got JUnit testing working as part of the headless build for our RCP application.

我刚刚让 JUnit 测试作为我们 RCP 应用程序的无头构建的一部分工作。

I found this article - Automating Eclipse PDE Unit Tests using Antincredibly helpful. It provides code and approach to get you started. However, a number of things that I discovered:

我发现这篇文章 -使用 Ant 自动化 Eclipse PDE 单元测试非常有帮助。它提供了帮助您入门的代码和方法。然而，我发现了一些事情：

About the article's code

关于文章的代码

• there was only one bundle under tests (we have separated out our build process from the code, using Buckminster)
• there was only one test class.
• these were both effectively hardcoded into the build script

• 只有一个包在测试中（我们使用Buckminster将我们的构建过程从代码中分离出来）
• 只有一个测试班。
• 这些都被有效地硬编码到构建脚本中

About Eclipse PDE

关于 Eclipse PDE

• the uitestapplicationrequires another testApplication. Using coretestapplicationdoes not.
• as these applications are both in bundles that have dependencies on SWT. This is a deal killer in most circumstances, though not if your build machine is a Windows box. I would love to see these split into non-UI bundles.

• 在uitestapplication需要另一个testApplication。使用coretestapplication没有。
• 因为这些应用程序都在依赖于 SWT 的包中。在大多数情况下，这是一个交易杀手，但如果您的构建机器是 Windows 机器，则不是。我很想看到这些分成非 UI 包。

I found that the code provided was a good starting point, but had a number of the above assumptions implicit in their implementation.

我发现提供的代码是一个很好的起点，但在其实现中隐含了许多上述假设。

Having discovered these assumptions, doing the work was relatively straight forward.

发现这些假设后，工作就相对简单了。

Our new and shiny setup

我们新的闪亮的设置

• buckminster builds the bundles.
• target copies the bundles from the target platform, the org.eclipse.pde.runtime and org.eclipse.jdt.junit into a "tester-eclipse-install". This should take care of your Java Result 13problem.
• find the test fragments from looking at the workspace
• find the fragment host from looking at the manifest
• find the test classes from looking at the project in the workspace.
• register a PDETestListenermodified to handle multiple test classes
• invoke the tester-eclipse-install with the multiple test classes.

• buckminster 构建捆绑包。
• target 将来自目标平台的包、org.eclipse.pde.runtime 和 org.eclipse.jdt.junit 复制到“tester-eclipse-install”中。这应该可以Java Result 13解决您的问题。
• 通过查看工作区找到测试片段
• 通过查看清单找到片段主机
• 通过查看工作区中的项目找到测试类。
• 注册一个PDETestListener修改来处理多个测试类
• 使用多个测试类调用 tester-eclipse-install。

I also read Build and Test Automation for plug-ins and featuresbut we are not using PDE-Build directly.

我还阅读了插件和功能的构建和测试自动化，但我们没有直接使用 PDE-Build。

回答by liangzan

Looking at your exception, it says that the coretestapplication is missing. The ant target could be found at plugins/org.eclipse.test_3.1.0/library.xml:10

查看您的异常，它表示缺少 coretestapplication。ant 目标可以在 plugins/org.eclipse.test_3.1.0/library.xml:10 找到

This is actually a dependency issue. Eclipse needs to have all the plugins in order to build.

这实际上是一个依赖问题。Eclipse 需要拥有所有插件才能构建。

To configure it correctly, there're 2 files to look at.

要正确配置它，需要查看 2 个文件。

1. The product file
2. The feature.xml

1. 产品文件
2. 特性.xml

Product

产品

Make sure you the product file contains all the plugins you need.

确保您的产品文件包含您需要的所有插件。

After that, add the org.eclipse.rcp and org.eclipse.test features

之后，添加 org.eclipse.rcp 和 org.eclipse.test 功能

... plugins are above ...

...插件在上面...

<features>
      <feature id="mock_feature" version="1.0.0"/>
      <feature id="mock_feature_test" version="1.0.0"/>
      <feature id="org.eclipse.rcp" version="3.2.0.v20060609m-SVDNgVrNoh-MeGG"/>
      <feature id="org.eclipse.test" version="3.2.0.v20060220------0842282442"/>
 </features>

You need org.eclipse.test to run the tests, and org.eclipse.rcp to launch eclipse in order to run the tests.

您需要 org.eclipse.test 来运行测试，并需要 org.eclipse.rcp 来启动 eclipse 以运行测试。

Don't forget to set useFeatures to 'true'

不要忘记将 useFeatures 设置为 'true'

<product name="mock" id="com.example.mock" application="com.example.mock.application" useFeatures="true">

feature.xml

特征文件

Assuming you have a feature for testing, you must add 2 additional plugins.

假设您有一个用于测试的功能，您必须添加 2 个额外的插件。

... other plugins above ...

... 上面的其他插件 ...

<plugin
         id="org.apache.ant"
         download-size="0"
         install-size="0"
         version="0.0.0"/>

   <plugin
         id="org.eclipse.core.runtime.compatibility"
         download-size="0"
         install-size="0"
         version="0.0.0"
         unpack="false"/>

THe tests need org.apache.ant to run the tests and org.eclipse.core.runtime.compatibility to launch.

测试需要 org.apache.ant 来运行测试和 org.eclipse.core.runtime.compatibility 来启动。

Another gotcha

另一个问题

Ensure that in your target eclipse(the copy of eclipse that you use to build against), there's only 1 copy of each plugin. For example if there're 2 versions of com.ibm.icu plugins in the plugin folder, eclipse would use the newer one. As the pde build plugin is configured to use a specific version, eclipse would complain that it cannot find the particular plugin even when it is there.

确保在您的目标 eclipse（您用于构建的 eclipse 副本）中，每个插件只有 1 个副本。例如，如果插件文件夹中有 2 个版本的 com.ibm.icu 插件，eclipse 将使用较新的一个。由于 pde 构建插件被配置为使用特定版本，eclipse 会抱怨它无法找到特定插件，即使它在那里。

Some thoughts

一些想法

The whole process of building eclipse could be a lot better. In fact I got the process mostly by trial and error. The documentation is outdated and sparse. The error messages doesn't help. It only leaves you feeling helpless and frustrated. Let's hope this post helps a fellow programmer save some time!

构建eclipse的整个过程可能会好很多。事实上，我主要是通过反复试验来获得这个过程的。文档已经过时且稀疏。错误消息没有帮助。它只会让你感到无助和沮丧。让我们希望这篇文章能帮助其他程序员节省一些时间！

回答by AMilassin

As an alternative to Ant, I've had good experience in using the brand new Maven+Tycho with Hudson. Tycho provides complete support for Osgi and Eclipse development in Maven. It's currently under heavy development, but most of the features I've needed worked. It needs only very little configuration from your side, because it can parse MANIFEST.MF files.

作为 Ant 的替代方案，我在使用全新的 Maven+Tycho 和 Hudson 方面有很好的经验。Tycho 为 Maven 中的 Osgi 和 Eclipse 开发提供了完整的支持。它目前正在大力开发中，但我需要的大部分功能都可以使用。它只需要您进行很少的配置，因为它可以解析 MANIFEST.MF 文件。

If you have some experience with Maven it's not very hard to start working with it. Hudson is a bit more problematic because of missing Maven 3 support. (the development version of Maven 3 is used by Tycho)

如果您对 Maven 有一些经验，那么开始使用它并不难。由于缺少 Maven 3 支持，Hudson 的问题有点多。（第谷使用的是Maven 3的开发版）

Links for start:

开始链接：

• uncomplete user docs

• 不完整的用户文档

回答by Gunjan Aggarwal

For any one still looking for a way to execute Eclipse plugin tests outside Eclipse, the following command works for me:

对于仍在寻找在 Eclipse 之外执行 Eclipse 插件测试的方法的任何人，以下命令对我有用：

java -Xms40m -Xmx1024m -XX:MaxPermSize=512m -Dorg.eclipse.swt.browser.DefaultType=mozilla -Declipse.pde.launch=true -classpath C:\eclipse\eclipse-standard-luna-M2-win32-x86_64\eclipse\plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar org.eclipse.equinox.launcher.Main -port 22 -testLoaderClass org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader -loaderpluginname org.eclipse.jdt.junit4.runtime -classNames testpackage.testClass -application org.eclipse.pde.junit.runtime.uitestapplication -data C:\temp\log.temp -dev bin -consoleLog -testpluginname PluginName

-classpathshould be set to Eclipse launcher jar. You can get exact version for your Eclipse from eclipse.inifile.

-classpath应设置为 Eclipse 启动器 jar。您可以从eclipse.ini文件中获取 Eclipse 的确切版本。

-classNameis the junit plugin test file name

-className是junit插件测试文件名

-datais set to a temp file.

-data设置为临时文件。

-testpluginnameis the name of plugin you want to test.

-testpluginname是您要测试的插件的名称。