2

There are several posts I found while searching for best practice of where to put test code for an Eclipse plugin. Most of them suggest fragments like this

I have a plugin single sourced and it has two fragments, one for RCP and one for RAP.

Now if I create another fragment for testing I cannot access the RCP fragment API from the test fragment.

There is a header Eclipse-ExtensibleAPI, if set to true the host plugin will make its fragment APIs available. But it's available to other plugins that require it, not its own fragment(the test fragment).

Can anyone please help me on this?

Lii
  • 11,553
  • 8
  • 64
  • 88
coder11
  • 457
  • 3
  • 9

1 Answers1

4

This problem is a consequence of the Eclipse convention to put tests in separate projects. The purpose of this separation is to exclude test dependencies like JUnit, mocking frameworks, etc. from the main project. However, this reasoning is based on assumptions that become more and more obsolete. If you neither use PDE build nor plug-in tests, you might consider moving the tests into the same project that contains the source code.

I believe that unit tests belong to the source code of a project and should not be separated. Everyone who checks out the source code should also have the tests.

PDE build

Eclipse plug-in projects used to be built with PDE build which reads dependencies from the Manifest file and cannot distinguish between test-scoped and compile-scoped dependencies. While PDE build is still used inside the IDE for exporting, it has been replaced by tycho in most Eclipse projects including the platform itself. Tycho is based on Maven which allows for test-scoped dependencies that do not end up into the built artifact.

If you move the tests into the main project, you could add the test dependencies to the project build path or see if you can use m2e to manage dependencies.

Plug-in tests

Another assumption that lead to the separation of tests was that all tests are executed as so called plug-in tests. Plug-in tests require a running OSGi environment, they can be considered more integration tests than unit tests. Those tests should not need to access the internals of a fragment, but test the functionality of the host bundle with either fragment available in the environment.

Plain unit tests should not require an OSGi environment, hence they use the same classloader anyway and therefore don't need to be kept in fragments. If you build with tycho, you have to use maven-surefire instead of tycho-surefire, as the latter executes tests as plug-in tests.

ralfstx
  • 3,893
  • 2
  • 25
  • 41