Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
The Eclipse Platform is tested during every build by an extensive suite of automated tests. These tests are written using the JUnit test framework. This page contains links to information about how to run and create automated tests for the platform.
- 1 Correctness tests
- 2 Code coverage
- 3 Session tests
- 4 Performance tests
- 5 API tests
- 6 UI tests
The majority of automated tests are testing for program correctness. A test failure on these tests implies that program behaviour is not as expected by the tests.
Running tests from within Eclipse
Correctness tests can be run from within the Eclipse IDE using a "JUnit Plug-in Test" launch configuration:
- In the Package Explorer, select the test or test suite you want to run. Each test package typically contains a TestSuite class that contains all the tests in that package. Suites from multiple packages are then aggregated into higher level suites. Here are some useful suites to know about:
- org.eclipse.ui.tests.UiTestSuite - runs all UI tests
- org.eclipse.core.tests.runtime.AutomatedTests - runs all runtime tests
- org.eclipse.core.tests.resources.AutomatedTests - runs all resource tests
- Select Run > Run...
- Choose the "JUnit Plug-in Test" category, and click the button to create a new test
- On the "Main" tab, select the appropriate application for that test. Here are some important applications to know about:
- [No Application] - Headless Mode - for running headless core (runtime, osgi, resource) tests
- org.eclipse.ui.ide.workbench - for running UI tests
- Click Run.
Running with Tycho
Since adoption of Tycho, some tests have been enabled as part of the integration-test step of the Tycho build, relying on the tycho-surefire-plugin. Those tests are run automatically when launching mvn clean verify command on the whole platform code, or mvn clean verify -Pbuild-individual-bundles if you're building a subset of Platform. They can be skipped appending -DskipTests to the command-line.
Getting the required bundles
Check out the test plugin containing the tests you want to run, along with any prerequisite plug-ins. Here are some plug-ins you will likely need:
- org.junit - The JUnit test framework
- org.eclipse.test - The basic infrastructure for running Eclipse tests
- org.eclipse.core.tests.harness - Various utility pieces used by many tests
- org.eclipse.core.tests.runtime - Tests for the runtime component
- org.eclipse.core.tests.resources - Tests for the resources component
- org.eclipse.ui.tests.harness - Various utility pieces used by UI tests
- org.eclipse.ui.tests - Tests for the Eclipse UI
Support for JUnit4
Testing on Java 7
In some Java 7 implementations, the order of methods returned by java.lang.Class#getDeclaredMethods() is not consistent across runs. This method is used by JUnit to discover test methods, which means test order may change across executions. Generally each test method should be coded to not depend on test execution order, which also makes it easier for people to run individual tests when debugging and get consistent results. In some rare cases separate tests rely on each other, in which case you can use the test suite to hard-code a test execution order. There is also a convenience class OrderedTestSuite.java that you can use or copy for this purpose.
Platform uses JaCoCo as code-coverage tool. JaCoCo doesn't require additional configuration than setting up a Java agent, and doesn't require to modify any class file on the filesystem. There's a Maven plugin to enable it, which works perfectly with tycho-surefire.
Generate JaCoCo coverage data with Maven/Tycho
Parent pom for Platform defines a coverage profile that enables and configures the jacoco-maven-plugin for tests. So you can simply run mvn clean verify -Pjacoco ... and you'll get the jacoco.exec report file in the tests/target folder (or just target/ if there is no tests module).
The location where this .exec file is generated can be overriden by command line settings: -Djacoco.destFile=/some/better/path. As the coverage data gets appended to the output file, you should usually make sure that there is no such file already before running tests to ensure it's only going to contain data from your current build, not a previous one. Concretely, that means that you should delete the jacoco file before running any build.
CI builds with JaCoCo and SonarQube
A bunch of module builds are configured to report code quality hints to SonarQube, they are visible at https://hudson.eclipse.org/platform/view/SonarQube/ . For each of these jobs, a SonarQube dashboard is created. You can see it by clicking on the SonarQube link. Then, among other, you'll be able to browse the coverage data in the Web UI of SonarQube.
Example - Platfrom resources:
- Job: https://hudson.eclipse.org/platform/job/eclipse.platform.resources-SonarQube/
- Coverage report file: https://hudson.eclipse.org/platform/job/eclipse.platform.resources-SonarQube/lastSuccessfulBuild/artifact/jacoco.exec
- SonarQube (linked from Job page): https://dev.eclipse.org/sonar/dashboard/index/33441 . Coverage reports are on the right column, classes that have 100% coverage do not appear in drill-down details.
Importing a coverage session in the Eclipse IDE with EclEmma
EclEmma provides a very good integration of JaCoCo reports into the Eclipse IDE, with metrics view, browsable coverage and highlighting lines according to whether they were covered or not. You can either let EclEmma run your tests from your IDE and it will enable coverage for this test, or reuse a previous jacoco.exec to analyze it in the IDE. This jacoco.exec can be one you generated locally by running tests with coverage enabled, or one that is archived in the SonarQube job of your choice containing data from the last execution of that job. Once you've chosen a jacoco.exec, simply Use File > Import... in the IDE, and import it as Coverage session. EclEmma will guide you to enjoy coverage.
Taking advantage of coverage
There are several ways of taking advantage of coverage. Here is one which seems relevant for Eclipse development: rather than focusing on the coverage metrics, coverage can be used to detect not covered code and decide on what tests to add. This uses coverage as a way to identify which critical pieces of code seem to be missing test coverage. If those are pretty critical, difficult, error-prone, frequently changes... that are not covered, it most likely means that in order to provide efficient error detection for the project, some effort could be spent on writing a test that verify this critical part to avoid regressions later. Gor example, if you're about to make some refactoring, it's interesting to check whether the code you're about to change is covered, in order to detect potential issues with your change, and if the code isn't covered then it's worth considering the addition of a test as a "preparation" of your refactoring.
Focusing on the percentage may be wrong: indeed, in Java and UI development, it's pretty frequent that some code is boilerplate, or even is never meant to be invoked in realistic scenarios. Things such as Exception handling are sometimes pure defensive programming and there is not much profit in making extra-effort to cover those lines.
Session Tests in Eclipse are tests that require that a new Eclipse session be launched for every test case run. Thus, they have additional requirements regarding controling the environment test cases are run (VM, set of plug-ins available, configuration, instance location, command line parameters) and how results are communicated back to the test runner.
See the Performance Tests How-to
Profiling performance tests
It can be very useful to capture profiling data for performance tests, to help track down where the time is going. To ensure you are profiling exactly the same code paths that are running in the automated performance tests, you can attach a headless profiler to the performance tests within the test suite. Here are steps to attach a headless YourKit agent to a performance test. The resulting snapshots can later be opened for analysis from the YourKit client:
- Download the tests for the build you are interested in (available from same download page as the build itself).
- Unzip the test framework, and follow the instructions in the readme.html to configure your tests
- Create a properties file (let's say profile.properties) with the following contents:
- Invoke the performance test and specify the properties file location:
runtests "-Dtest.target=performance" -properties profile.properties <yourtarget>
If your performance test is a session test, a more complex spell is needed in your profile.properties file:
This instructs the Session Tests framework to specify the provided vm arguments on each nested invocation that runs the session test. Note the session test framework override mechanism requires escaping '=' characters with '==', separating multiple arguments with a ';' character rather than a space, and omitting the leading '-' character.
The above options will instruct the profile agent to start CPU sampling immediately on startup, and to save a performance snapshot on exit. YourKit supports various other options for configuring the headless profile agent.
The Eclipse project also runs an suite of API tests during builds. These tests capture problems such as breaking API changes, and correct evolution of bundle version numbers. For more details on these tests, refer to PDE/API_Tools.
The table below gathers pros and cons of tools making UI testing easier. It should help developers to choose the most appropriate tool.
Commercial, free license available for Open Source projects and academic purposes
Open Source, EPL
Tests specified by drag & drop without need to record.
|Automated GUI Recorder
Yes, free trial available
The table is in progress. Feel free to update it, if you know useful features or serious limitations of the mentioned tools. You are also welcome to add new tools.
More we know about those tools, easier to choose the best one.
Notes on what you should be evaluating on
- CI support -- ability to run tests from command line/ant
- Cross platform support -- developers use a variety of platforms -- windows, linux, mac
- Scripting capabilities -- vendor script/Java/jruby ?
- Reporting capabilities -- html/xml/push to database ?
Back to Eclipse Project home