We have a rather larger Eclipse RCP application and are not sure how to properly test it's plugins.
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!
Running Single Test Class. To run JUnit 5 tests from Java code, we'll set up an instance of LauncherDiscoveryRequest. It uses a builder class where we must set package selectors and testing class name filters, to get all test classes that we want to run.
Select the individual tests that you want to run, open the right-click menu for a selected test and then choose Run Selected Tests (or press Ctrl + R, T). If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution in the settings menu of the toolbar.
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).
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With