Continuous integration is key

Continuous integration is a way to try and mitigate the issues that we come across by only building and testing code on our development machines. Our continuous integration server will monitor our source code repository and then every time it detects a change, it will trigger a series of actions. The first action will be to build the code, running any tests that it can as it builds the code (usually unit tests), and then creating a deployable artifact. This artifact would then usually be deployed to a server that is a replica of the live environment. Once this code has been deployed to a server, the rest of our tests will be run against that server to ensure that everything is working as expected. If things do not work as expected, the build fails and the development team is notified so that they can fix the problems. It's important to note that we only build the artifact once; if we rebuild it multiple times, we would be testing artifacts that are potentially different at every step (maybe it was built with a different version of Java; maybe it had different properties applied to it, and so on).

With continuous integration, we are looking for a workflow such as this:

Most continuous integration systems also have big visible dashboards to let people know the status of the build at all times; if your screen ever goes red, people should stop what they are doing and fix the problem as soon as possible.

Let's have a look at how easily we can get our tests running on a continuous integration server. This is not going to be a fully-featured continuous integration setup, just enough for you to run the tests we have built so far.

The first thing we are going to do is configure a Maven profile. This will enable us to isolate our Selenium tests from the rest of the build if desired, so that we can turn them in a separate UI block of tests on our continuous integration server. This is a very simple change to our POM; we are simply going to wrap our <build> and <dependencies> blocks with a profile block. the code will look like this:

<profiles>
<profile>
<id>selenium</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>com.lazerycode.selenium</groupId>
<artifactId>driver-binary-downloader-maven-
plugin</artifactId>
<version>${driver-binary-downloader-maven-
plugin.version}</version>
<configuration>
<rootStandaloneServerDirectory>
${project.basedir}/src/test/
resources/selenium_standalone_binaries
</rootStandaloneServerDirectory>
<downloadedZipFileDirectory>
${project.basedir}/src/test/
resources/selenium_standalone_zips
</downloadedZipFileDirectory>
<customRepositoryMap>${project.basedir}
/src/test/resources/RepositoryMap.xml
</customRepositoryMap>

<overwriteFilesThatExist>
${overwrite.binaries}
</overwriteFilesThatExist>
</configuration>
<executions>
<execution>
<goals>
<goal>selenium</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${maven-failsafe-plugin.version}
</version>
<configuration>
<parallel>methods</parallel>
<threadCount>${threads}</threadCount>
<systemPropertyVariables>
<browser>${browser}</browser>
<headless>${headless}</headless>
<!--Set properties passed in by the
driver binary downloader-->
<webdriver.chrome.driver>
${webdriver.chrome.driver}
</webdriver.chrome.driver>
<webdriver.ie.driver>
${webdriver.ie.driver}
</webdriver.ie.driver>
<webdriver.opera.driver>
${webdriver.opera.driver}
</webdriver.opera.driver>
<webdriver.gecko.driver>
${webdriver.gecko.driver}
</webdriver.gecko.driver>
<webdriver.edge.driver>
${webdriver.edge.driver}
</webdriver.edge.driver>
</systemPropertyVariables>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>

As you can see, we have created a profile called selenium. This will give us the ability to toggle the execution of our Selenium tests as part of the build. If you specifically activate the selenium profile now, it will only execute your Selenium tests:

mvn clean verify -Pselenium 

You can also specifically prevent Selenium tests from running with this:

mvn clean verify -P-selenium 

You will also notice that we have added <activeByDefault>true</activeByDefault>; this will ensure that this profile is active if no profiles are specified on the command line, so you will find the following command:

mvn clean verify 

The preceding command will run our Selenium tests as part of a normal build, and the SCM hooks that we set up previously still do their job.

Next, we are going to look at two popular continuous integration servers, TeamCity and Jenkins. TeamCity is popular in a lot of corporate environments, so it's useful to have a basic understanding of it. Jenkins is prolific; you will probably see a Jenkins install at some point in your career if you haven't already.

So, why are we going into such detail on this subject? What has it got to do with Selenium?

  • First, I want to show you how easy it is to set up a Maven project on a CI server. It shows just how useful using a build/dependency management tool such as Maven is.
  • Secondly, it is good to get some experience setting something up on a couple of CI servers; it's probably something you will be asked to do at some point.
  • Finally, CI servers will have some limitations out of the box. We are going to have a look at how we can get around these problems with minimal effort.
..................Content has been hidden....................

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