Sometimes it's useful to be able to pass information between steps. For example, you might need to check that a client's details entered into a registration form appear correctly on a confirmation page later on.

You could do this by passing values from one step to another, however this tends to clutter up the steps. Another approach is to use the Thucydides test session, which is essentially a hash map where you can store variables for the duration of a single test. You can obtain this session map using the Thucydides.getCurrentSession() static method.

As illustrated here, you can p

@Step
public void notes_publication_name_and_date() {
    PublicationDatesPage page = pages().get(PublicationDatesPage.class);
    String publicationName = page.getPublicationName();
    DateTime publicationDate = page.getPublicationDate();

    Thucydides.getCurrentSession().put("publicationName", publicationName);
    Thucydides.getCurrentSession().put("publicationDate", publicationDate);
}

Then, in a step invoked later on in the test, you can check the values stored in the session:

public void checks_publication_details_on_confirmation_page() {

    ConfirmationPage page = pages().get(ConfirmationPage.class);

    String selectedPublicationName = (String) 
Thucydides.getCurrentSession().get("publicationName");
    DateTime selectedPublicationDate = (DateTime) 
Thucydides.getCurrentSession().get("publicationDate");

    assertThat(page.getPublicationDate(), is(selectedPublicationName));
    assertThat(page.getPublicationName(), is(selectedPublicationDate));

}

If no variable is found with the requested name, the test will fail. The test session is cleared at the start of each test.

Web tests are as a rule much slower than other types of tests, but they can be sped up significantly by running them in parallel. However, this is often harder to implement than it sounds. The latest version of Thucydides (version 0.6.0) comes with support for running parallel test batches, making this task much easier.

Web tests make good candidates for concurrent testing, in theory at least, but the implementation can be tricky. For example, although it is easy enough to configure both JUnit and easyb to run tests in parallel, running several webdriver instances of Firefox in parallel on the same display, for example, tends to become unreliable.

The natural solution in this case is to split the web tests into smaller batches, and to run each batch on a different machine and/or on a different virtual display. When each batch has finished, the results can be retrieved and aggregated into the final test reports.

However splitting tests into batches by hand tends to be tedious and unreliable - it is easy to forget to add a new test to a batch, for example, or have unevenly-distributed batches.

The latest version of Thucydides lets you do this automatically, by splitting your test cases evenly into batches of a given size. In practice, you run a build job for each batch. You need to specify two parameters when you run each build: the total number of batches being run (thucydides.batch.count), and the number of the batch being run in this build (thucydides.batch.number).

For example, the following will divide the test cases into 3 batches ("thucydides.batch.count"), and only run the first test in each batch (thucydides.batch.number):

    mvn verify -Dthucydides.batch.count=3 -Dthucydides.batch.number=1

This will only work with the JUnit integration. However this feature is also now supported in easyb (as of easyb version 1.5), though using different parameters. When using the Thucydides easyb integration, you also need to provide the equivalent options for easyb:

    mvn verify -Deasyb.batch.count=3 -Deasyb.batch.number=1

If you have both easyb and JUnit Thucydides tests, you will need to specify both options.

Parallel web tests on Jenkins

This approach is easy to set up on Jenkins using a multi-configuration build. In the following screenshot, we are running a multi-configuration build to run web tests across three batches. We use a single user-defined parameter (BATCH_NUMBER) to define the batch being run, passing this parameter into the Maven build job properties we discussed above.

The most robust way to aggregate the build results from the different batches is to set up a second build job that runs after the test executions, and retrieves the build results from the batch jobs. You can use the Jenkins Copy Artifacts plugin to do this. First, ensure that the multi-configuration build archives the Thucydides reports, as shown here:

This build will then trigger another, freestyle build job. This job needs to copy the Thucydides report artifacts from the matrix build jobs into the current workspace, and then run the mvn thucydides:aggregate command to generate the Thucydides aggregate reports. The matrix build job reports need to be copied one-by-one for each batch, as the current version of the Copy Artifacts plugin does not support copying from multiple projects in the same action.

Then make sure you publish the generated HTML reports (which will be in the target/site/thucydides directory) for easy access to the test results.

This simple example shows a parallel test running 3 batches - this brought the test execution time from 9 minutes to slightly over 1 minute. Results will vary, of course, but a typical real-world set of web tests would have a larger number of batches.

Hamcrest is a neat little library that lets you write more fluent and readable tests. For example, rather than writing:

    assertEquals("red", color);

you would write:

    assertThat(color,is("red"));

This makes for tests that express their intent much more clearly, which in turn makes the tests easier to understand and to maintain, and more likely to be correct. This is generally considered to be a Good Thing.

A version of Hamcrest is actually bundled with JUnit. However it is somewhat dated, and the more recent versions of Hamcrest come with a lot more features, particularly with regards to working with collections. You can use the latest version of Hamcrest by using the junit-dep dependency instead of junit, and configuring your dependencies as shown here:

    <dependency>
	    <groupId>junit</groupId>
	    <artifactId>junit-dep</artifactId>
	    <version>4.10</version>
	    <scope>test</scope>
	    <exclusions>
	        <exclusion>
	            <groupId>org.hamcrest</groupId>
	            <artifactId>hamcrest-core</artifactId>
	        </exclusion>
	    </exclusions>
	</dependency>
	<dependency>
	    <groupId>org.hamcrest</groupId>
	    <artifactId>hamcrest-library</artifactId>
	    <version>1.3.RC2</version>
	</dependency>

You can check the size of a collection directly:

    List colors = Arrays.asList("red","green","blue");
    assertThat(colors, hasSize(3));

You can also check the exact contents of a collection:

    List colors = Arrays.asList("red","green","blue");
    assertThat(colors, contains("red", "green", "blue"));

This last example checks both the contents and the order of the collection. If you are only interested in the contents, you can use containsInAnyOrder:

    List colors = Arrays.asList("red","green","blue");
    assertThat(colors, containsInAnyOrder("green", "red", "blue"));

You can also check that a condition is true for every item in a list:

    List ages = Arrays.asList(21, 25,30);
    assertThat(ages, everyItem(greaterThan(18)));

This version is a release candidate, so there might be a few rough edges before the final version. And since the artifact names have changed, you need to be careful to exclude any references to hamcrest-all used by other libraries (lambdaj, for example, uses Hamcrest).