It is important to note that there is no guarantee in which order tests will be run.

We are using the threadCount con guration setting to control how many tests we run in parallel but, as you may have noticed, we have not speci ed a number. Instead, we have used the Maven variable ${threads}; this will take the value of the Maven property threads that we de ned in our properties block and pass it into threadCount.

Since threads is a Maven property, we are able to override its value on the command line by using the -D switch; if we do not override its value, it will use the value we have set in the POM as a default.

So let's run the following command:

mvn clean install

This command will use the default value of 1 in the POM le. However, if we use this:

mvn clean install -Dthreads=2

It will now overwrite the value of 1 stored in the POM le and use the value 2 instead. As you can see this gives us the ability to tweak the number of threads that we use to run our tests without making any code changes at all.

So we have used the power of Maven and the maven-failsafe plugin to set the number of threads that we want to use when running our tests in parallel. Now we need to modify our code to take advantage of this.

Previously, we were instantiating an instance of FirefoxDriver in each of our tests. Let's pull this out of the test, and put browser instantiation into its own class called WebDriverThread. We will then add a class called DriverFactory that will deal with the marshalling of the threads.