Selenium Docker Integration Through Jenkinsfile – Part 1 – Setting Up Tests & Dependencies

Overview:

We already have seen how to create a disposable selenium grid at run time using Docker.

In this article, We are going to see how to run our automated tests inside docker container & what kind of benefits it brings us!

Udemy – Selenium WebDriver With Docker:

TestAutomationGuru has released a brand new course in Udemy on Selenium WebDriver with Docker. 14 hours course which starts with installing docker from scratch and goes all the way up to running dockerized selenium tests on AWS cloud. Please access the above link which gives you the special discount.  You can also get your money back if you do not like the course within 30 days.

Note:

We already have few posts on running automated tests inside Docker container. But those are specifically for a Java-Maven projects with Maven-Docker plugin.

Then, why are we creating another post with same content?

Well… As part of this article, we would be using the same Java/Maven framework as we used in the article above. But we would not use Maven plugin to create Docker image. Instead we would use Jenkins declarative pipeline to create image and push it to Docker Hub. If you are NOT using Jenkins, I would suggest you to follow the above approaches & skip this series!

This approach would be better as it completely separates Docker image build process from Maven. It could be useful for any functional test automation project. Not specific to Java.

Even if you are not a Java user, I would still encourage you to continue reading this article to get some idea. Part 2/Part 3 of this series are very generic. Not Java Specific. So, I hope you would get good understanding.

For the sake of creating a separate series, I am shamelessly copying some content from the above article just for this article.

Challenges In Test Execution:

We already have simplified our selenium grid set up using docker using the above articles. But we still face few challenges. Your tests still have few dependencies to run them!

  • Test depends on specific version of java (like java 8) / nodejs / python etc
  • Host should have Maven / Ant / Gradle / pip other build tools installed
  • Tests depend on number of 3rd party jar files and other files like csv etc.
  • Tests depend on few jar files which are not part of maven repo!!
  • Remote slaves need to be set up with the build tools, java and any dependent jar files to execute the tests.

Managing these dependencies & Setting up remote slaves are time-consuming for big applications which has thousands of test cases to run on a daily basis on a multiple slave machines.

container-test-prop

That too, if you are planning to move AWS /cloud in future, How can you set this up all programmatically?

We will see how docker could help us here!!

Sample Test Framework:

I have uploaded a sample project here in GitHub. You could fork this project in Github or use your own project in Java/Javascript/Python etc.

  • My project is a Maven project (without Docker plugin).
  • If you are not a Maven user, assume that
    • src directory contains all the page objects and tests scripts
    • suite directory contains test suites / tests grouped based on the business module
    • pom.xml contains list of dependencies – It is like package.json for nodeJS project.
  • Dockerfile – we would cover that later.

Page Objects & Tests:

  • src directory contains 2 page objects – here
    • SearchPage – A Page object to access google.com and enters the given text in the search field and retrieves the search results.
    • OrderPage – A Page object to access demoqa site to get the list of items for the given category.
  • We also have 2 tests for the above pages. Both tests extend below BaseTest.
    • This BaseTest assumes we pass browser (chrome/firefox) and seleniumHubHost (IP address/hostname of Gird)
public class BaseTest {

    protected WebDriver driver;
    
    @BeforeTest
    public void setUp() throws MalformedURLException {
        
        DesiredCapabilities dc = DesiredCapabilities.chrome();

        if (System.getProperty("browser").equals("firefox"))
            dc = DesiredCapabilities.firefox();

        String host = System.getProperty("seleniumHubHost");
        
        driver = new RemoteWebDriver(new URL("http://" + host + ":4444/wd/hub"), dc);
        
    }

    @AfterTest
    public void tearDown() throws InterruptedException {
        driver.quit();
    }  
}

Test Suites:

The project contains 2 suite files. Lets assume that each suite is for testing specific business module of the application. Here in our case,

  • search-module
  • order-module.

Building Project Locally:

  • Clone the above GitHub project
  • Run this command under project root directory
mvn clean package -DskipTests
  • The above command does the following
    • compiles and packages the page objects and tests in a container-test.jar under target folder
    • copies all the dependencies (jars) under target/libs folder
  • To run the test we need to run below commands. (I assume that you have a selenium grid is up and running.)
cd target
java -cp container-test.jar:libs/* -DseleniumHubHost=10.11.12.13 -Dbrowser=chrome org.testng.TestNG ../suite/search-module.xml
  • Now you could see the tests running in your Grid.
  • You can modify this project as per your project requirements and ensure that above command works just fine after your modification.
  • At this point, you should have a project which should just work fine in your local. Not through your IDE. It should work fine via command line.

Test Results:

When you run the above test using command line, make a note of the result files it creates. TestNG by default creates a test-output directory under project root directory and stores all the results files there. If your are using a different framework, ensure that you create a separate directory for your results. We might need this info later in this series.

Summary:

We created a simple project with our page objects, tests and test suites. We built the project through build tools (here it is Maven) & ensured that it works fine through command line.

Once you have a working project, list the dependencies you would need to run the project in a completely new environment. We would need those to create our Dockerfile which will be covered in the next article.

Happy Testing & Subscribe 🙂

 

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.