Time for action – running automated tests

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.

  1. Move the com.packtpub.e4.junit.plugin project underneath the com.packtpub.e4.parent project.
  2. Add the line <module>com.packtpub.e4.junit.plugin</module> to the parent pom.xml file.
  3. Add the SWTBot repository to the parent pom.xml file:
      <properties>
    <swtbot>http://download.eclipse.org/technology</swtbot>
  </properties>
  ...
  <repositories>
    <repository>
      <id>swtbot</id>
      <layout>p2</layout>
      <url>${swtbot}</url>
    </repository>
  </repositories>

    Note

    For Kepler (4.3), SWTBot must be version 2.1.1 or higher.

  4. Copy the pom.xml file from the clock plugin to the junit.plugin project.
  5. Modify the packaging to <packaging>eclipse-test-plugin</packaging>.
  6. Change the artifactId to com.packtpub.e4.junit.plugin.
  7. 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>
  8. Now, running mvn integration-test should run the tests when not run on OS X. If run on an OS X, a line must be added to the configuration for JVM:
    <configuration>
  <useUIHarness>true</useUIHarness>
  <useUIThread>false</useUIThread>
  <argLine>-XstartOnFirstThread</argLine>
  ...
</configuration>

    Although the tests run, they fail, 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.xml file so that the 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:

    <configuration>
  <useUIHarness>true</useUIHarness>
  <useUIThread>false</useUIThread>  
  <dependencies>
    <dependency>
      <type>p2-installable-unit</type>
      <groupId>com.packtpub.e4</groupId>
      <artifactId>com.packtpub.e4.clock.ui</artifactId>
    </dependency>
    <dependency>
      <type>p2-installable-unit</type>
      <artifactId>org.eclipse.sdk.feature.group</artifactId>
    </dependency>
  </dependencies>
  ...
</configuration>
  9. Finally, run mvn integration-test and the tests should run and pass.

What just happened?

The tycho-surefire-plugin allows SWTBot applications to be launched. The tests are executed and then a return value indicates 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 appears 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.

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 using individual plug-ins. In the example, the clock.ui plugin was added explicitly and the org.eclipse.sdk.feature was added as well. Note that the naming convention for the p2 feature's installable units is to add the suffix .feature.group to the end of the name; so the clock.ui plug-in dependency could be replaced with com.packtpub.e4.feature.feature.group as a dependency instead.

Using features for dependencies makes it 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 need only be added to the feature and it will apply to both the update site, as well as runtime and test projects.

Finally, it is possible to determine whether or not a build is running on a Mac box dynamically, and switch in a value for the -XstartOnFirstThread argument. This can be achieved by setting a property using profiles which 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).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset