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

时间:2022-06-04 10:55:24

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, here and 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 task / commandline命令,不会产生可观察到的副作用,并返回值“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 want to use something like ant + cruise control, but I can't even get the unit tests to run at all outside 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 +巡航控制这样的东西,但我甚至无法让单元测试在Eclipse之外运行。我说“类似的东西”,因为还有其他技术可以完成同样的事情,而且我不会那么挑剔,因为它丢弃了一个可行的解决方案,因为它使用的是Say,Maven或Buckminster,如果这些技术使这个变得更容易。

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.

7 个解决方案

#1


12  

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 Ant incredibly 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)
  • 测试中只有一个包(我们使用Buckminster从代码中分离出构建过程)

  • there was only one test class.
  • 只有一个测试类。

  • these were both effectively hardcoded into the build script
  • 这些都被有效地硬编码到构建脚本中

About Eclipse PDE

  • the uitestapplication requires another testApplication. Using coretestapplication does not.
  • uitest应用程序需要另一个testApplication。使用coretestapplication不会。

  • 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.
  • 因为这些应用程序都是依赖于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.
  • buckminster构建捆绑包。

  • 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 13 problem.
  • target将目标平台上的bundle,org.eclipse.pde.runtime和org.eclipse.jdt.junit复制到“tester-eclipse-install”中。这应该解决您的Java Result 13问题。

  • 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 PDETestListener modified to handle multiple test classes
  • 注册修改的PDETestListener以处理多个测试类

  • invoke the tester-eclipse-install with the multiple test classes.
  • 使用多个测试类调用tester-eclipse-install。

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

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

#2


3  

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

-classpath should be set to Eclipse launcher jar. You can get exact version for your Eclipse from eclipse.ini file.

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

-className is the junit plugin test file name

-className是junit插件测试文件名

-data is set to a temp file.

-data设置为临时文件。

-testpluginname is the name of plugin you want to test.

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

#3


2  

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

看看你的异常,它说缺少核心测试应用程序。 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. 产品文件

  3. The feature.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的副本)中,每个插件只有一个副本。例如,如果插件文件夹中有两个版本的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!

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

#4


0  

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-task从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构建脚本并没有真正用于我们需要做的事情。

#5


0  

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有点问题。 (Tycho使用Maven 3的开发版本)

Links for start:

开始链接:

#6


-1  

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.

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

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都会为您运行测试。关于运行哪些测试很聪明,只运行你需要的测试。如果发生任何错误,它会清楚简明地报告。这为您提供了有关代码语义正确性的即时反馈,就像现代IDE为您提供有关语法错误的即时反馈一样。

#7


-1  

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

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

#1


12  

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 Ant incredibly 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)
  • 测试中只有一个包(我们使用Buckminster从代码中分离出构建过程)

  • there was only one test class.
  • 只有一个测试类。

  • these were both effectively hardcoded into the build script
  • 这些都被有效地硬编码到构建脚本中

About Eclipse PDE

  • the uitestapplication requires another testApplication. Using coretestapplication does not.
  • uitest应用程序需要另一个testApplication。使用coretestapplication不会。

  • 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.
  • 因为这些应用程序都是依赖于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.
  • buckminster构建捆绑包。

  • 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 13 problem.
  • target将目标平台上的bundle,org.eclipse.pde.runtime和org.eclipse.jdt.junit复制到“tester-eclipse-install”中。这应该解决您的Java Result 13问题。

  • 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 PDETestListener modified to handle multiple test classes
  • 注册修改的PDETestListener以处理多个测试类

  • invoke the tester-eclipse-install with the multiple test classes.
  • 使用多个测试类调用tester-eclipse-install。

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

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

#2


3  

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

-classpath should be set to Eclipse launcher jar. You can get exact version for your Eclipse from eclipse.ini file.

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

-className is the junit plugin test file name

-className是junit插件测试文件名

-data is set to a temp file.

-data设置为临时文件。

-testpluginname is the name of plugin you want to test.

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

#3


2  

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

看看你的异常,它说缺少核心测试应用程序。 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. 产品文件

  3. The feature.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的副本)中,每个插件只有一个副本。例如,如果插件文件夹中有两个版本的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!

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

#4


0  

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-task从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构建脚本并没有真正用于我们需要做的事情。

#5


0  

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有点问题。 (Tycho使用Maven 3的开发版本)

Links for start:

开始链接:

#6


-1  

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.

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

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都会为您运行测试。关于运行哪些测试很聪明,只运行你需要的测试。如果发生任何错误,它会清楚简明地报告。这为您提供了有关代码语义正确性的即时反馈,就像现代IDE为您提供有关语法错误的即时反馈一样。

#7


-1  

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

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