Although a plug-in's code-based tests (those under src/test/java) will be run automatically as part of a Maven build, very often it is necessary to test them in a running Eclipse application. The previous chapter covered creating automated UI tests; now they will be run as part of the automated build.
- Move the
com.packtpub.e4.junit.pluginproject underneath thecom.packtpub.e4.parentproject. - Add the line
<module>com.packtpub.e4.junit.plugin</module>to the parentpom.xmlfile. - Copy the
pom.xmlfile from thecom.packtpub.e4.clock.uiplug-in to thecom.packtpub.e4.junit.pluginproject. - Modify the packaging type to
<packaging>eclipse-test-plugin</packaging>. - Change the
artifactIdtocom.packtpub.e4.junit.plugin - To run the Tycho tests, add the following as a build plugin:
<build> <sourceDirectory>src</sourceDirectory> <plugins> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-surefire-plugin</artifactId> <version>${tycho.version}</version> <configuration> <useUIHarness>true</useUIHarness> <useUIThread>false</useUIThread> <product>org.eclipse.sdk.ide</product> <application>org.eclipse.ui.ide.workbench</application> </configuration> </plugin> </plugins> </build> - Now running
mvn integration-testshould run the tests. If run on OS X, a line must be added to the configuration for the JVM:<configuration> <useUIHarness>true</useUIHarness> <useUIThread>false</useUIThread> <argLine>-XstartOnFirstThread</argLine> ... </configuration>
- In order for the tests to make the JDT available, it needs to be added to the target platform. Add the Java Development Tools to the target platform, or add the following line to the
com.packtpub.e4.target.mars.targetfile:<unit id="org.eclipse.jdt.feature.group" version="3.11.2.v20160212-1500"/>
- Although the tests run, they do not pass, because the SWTBot environment is giving the bare minimum dependencies required for the JUnit plug-in. In this case, it doesn't even include the clock plug-in developed earlier.
To fix this, a dependency needs to be added to the
pom.xmlfile so that the test runtime can instantiate the correct workspace, including both the clock plug-in and the Eclipse SDK—since the tests rely on the workbench for the Open View command and the JDT for the Java project. This is achieved by defining atarget-platform-configurationplugin and specifying either Eclipse features or specific bundles by their ID:<plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho.version}</version> <configuration> <dependency-resolution> <extraRequirements> <requirement> <type>p2-installable-unit</type> <id>com.packtpub.e4.clock.ui</id> <versionRange>0.0.0</versionRange> </requirement> <requirement> <type>eclipse-feature</type> <id>org.eclipse.platform</id> <versionRange>0.0.0</versionRange> </requirement> <requirement> <type>eclipse-feature</type> <id>org.eclipse.jdt</id> <versionRange>0.0.0</versionRange> </requirement> </extraRequirements> </dependency-resolution> </configuration> </plugin> - If a test failure with the
testUImethod occurs (because the word Eclipse isn't seen in the title) change the implementation to:if (shells[i].isVisible()) { String text = shells[i].getText(); if (text.contains("Eclipse") || text.contains("Resource") || text.contains("Java")) { found = true; } } - Finally, run
mvn integration-testand the tests should run and pass.
The tycho-surefire-plugin allows SWTBot applications to be launched, the tests executed, and then a return value indicating whether or not they were successful to be passed back to the Maven build process.
Although it may seem that specifying the product or application will also bring in the necessary dependencies, that isn't the case. When the SWTBot test is run, it seems to pay no attention to the application or product when considering dependencies. As a result, these have to be added manually to the pom.xml file so that SWTBot sets up the right environment for the tests to run in.
The SWTBot tests written previously also had an implicit dependency on the SDK, from asserting the title of the workbench window to expecting the Show View menu to be present. These are examples of loosely coupled dependencies; they aren't code-related, but to run, they do require the environment to be pre-seeded with the necessary plug-ins and features.
Normally, if applications or features are being developed, then these can be used to add the required dependencies instead of individual plug-ins. In the example, the com.packtpub.e4.clock.ui plug-in was added explicitly and the org.eclipse.platform and org.eclipse.jdt features were added as well.
Note
Note that the naming convention for P2 feature installable units is to add the suffix .feature.group to the end of the name; so the com.packtpub.e4.clock.ui plug-in dependency could be replaced with com.packtpub.e4.feature.feature.group as a dependency instead (since the feature contains the plug-in).
Using features for dependencies makes them easier to maintain, as the test project can depend only on the feature, and the feature can depend on the necessary plug-ins. If a dependency needs to be added, it has to be added only to the feature and it will apply to the update site, runtime, and test projects.
Finally, it is possible to determine whether or not a build is running on a macOS operating system dynamically, and use a value for the -XstartOnFirstThread argument. This can be achieved by setting a property using profiles that are automatically selected based on the operating system:
<profiles>
<profile>
<id>OSX</id>
<activation>
<os><family>mac</family></os>
</activation>
<properties>
<swtbot.args>-Xmx1024m -XstartOnFirstThread</swtbot.args>
</properties>
</profile>
<profile>
<id>NotOSX</id>
<activation>
<os><family>!mac</family></os>
</activation>
<properties>
<swtbot.args>-Xmx1024m</swtbot.args>
</properties>
</profile>
</profiles>The OSX profile is automatically enabled for the mac family builds, and the NotOSX profile is automatically enabled for any non mac family builds (with the negation character ! at the start of the family name).