6

We have a rather larger Eclipse RCP application and are not sure how to properly test it's plugins.

  • For each plugin, there is a test fragment that contains Unit tests.
  • For smaller tests, that do not require the RCP Platform running, we simply invoke the "standard" JUnit test runner.

enter image description here

  • For tests, that require the RCP Platform, there is the possibility to test it using the JUnit plugin test runner.

enter image description here

  • For the JUnit plugin tests, it is possible to define which plugins are loaded when the RCP Platform starts up.

enter image description here enter image description here

  • Problem: Running JUnit Plugin Tests takes a lot of time (seconds instead of millicseconds for simple JUnit Test) and resources, since the RCP Platform and all plugins need to start up.

  • Question: How can I efficiently minimize the plugins that are run for the test? What options do I have to minimize my dependencies to the RCP Platform (such as Preferences Service and Extension Points)? Are there maybe some Mocking libraries or at least some best practices for mocking RCP Platform services?

Right now I cannot imagine to do some decent TDD with the JUnit plugin test runner, it just takes too long to execute these tests.

Any advice and experience on that topic very welcome!

kerner1000
  • 3,382
  • 1
  • 37
  • 57

2 Answers2

6

I can feel your pain: having plug-in tests sucks! And I haven't found a fully satisfying solution either.

While you probably could gain some (milli-?)seconds in that you reduce the required plug-ins to the absolute minimum, I found it impractical as changes in your dependency graph often require to adjust the launch configuration as well. And this gets worse if you have platform dependent fragments (i.e. SWT) in your (shared) launch configurations. I usually fall back to the all workspace and enabled target plug-ins option and haven't seen a notable difference in startup speed.

I am not aware of a mock library for the RCP platform.

Except for very simple cases, I would refrain from mocking parts of the platform as you could easily get the behavior wrong. See also this post: https://stackoverflow.com/a/31938571/2986905

My practice is to keep platform dependencies out of my application code as much as possible so that I can write plain JUnit tests. Custom abstractions over platform APIs can help here for recurring use cases.

In addition, a surprisingly large number of platform APIs can be used without the workbench running, like, of course, all SWT and JFace APIs, preferences, ... Thus writing small, simple classes with minimal dependencies again helps to stay away from plug-in tests. For example, separating the contents of a view from the IViewPart (or its e4 equivalent) allows writing tests without requiring a view and in turn a running workbench instance (pardon if I am stating the obvious).

Rüdiger Herrmann
  • 20,512
  • 11
  • 62
  • 79
  • 1
    Nice answer. Reminds on that one core recommendation in one of the books of Robert Martin: *where possible, write POJOs so you can properly unit test their logic*. – GhostCat Jun 21 '17 at 06:49
  • 1
    Thanks for contributing! I agree, I am trying to keep the Platform out of everything where possible. Unfortunately, I am not the only one writing code ;) The encapsulation of application model, platform and preferences/ UI is not really there for many classes. Refactorings to optimize testability are dangerous, since code is not properly tested ;) and speaking from experience, they sometimes have strange side effects and break things.. – kerner1000 Jun 21 '17 at 07:51
1

Plugin tests run significantly faster, if you change the default configuration to "headless mode", which will also prevent the annoying Eclipse Window to pop up during testing.

enter image description here

kerner1000
  • 3,382
  • 1
  • 37
  • 57