Lets set the scene

So, there you are… having a UI and an entire suite of manual test cases. These tests are tedious, take forever and lets be honest…can get repetitive and boring!

My friend, you are in the frontline for automating your testing!

Tools

Lets not beat around the bush – Selenium has been around for ages. The product has had millions of users, has become a W3 standard and is launching selenium 4 pretty soon.

This is the tool for us. 

There are others yes, most of which will wrap some selenium WebDriver capability into a pretty package and sell you that at a pretty penny.

Lets not get the wool pull over our eyes.  

We can do the same, implement at the same level and in fact, have far greater control on our test product ….cheaper, faster, better.

Ok, before we get butterflies in our tummies over this tool, there are some pitfalls…urhgggg, of course.

Not to worry, we have help – in our demo below, I will show you how I implemented Selenide – an open source project to fill the gaps that were obvious in Selenium 3.

You can read up on the tools here: 

Selenium

https://selenium.dev/downloads/

Selenide

A wrapper around selenium with a few more fluent apis for us to work with. therefore, it is my. preferred library. 

https://selenide.org/

Show me the baby trees(bacon is nice but baby trees are better)

Head on over to my github page and you will find a FEW implementations of UI testing,

https://github.com/suveerprithipal to find this code and more. Dont limit yourself. There are many ways of implementing this.

Here is one I’ve taken from https://github.com/suveerprithipal/selenideJava which implements Selenide.

https://github.com/suveerprithipal/selenideJava/blob/master/README.md

 * @author Suveer Prithipal

public class GoogleTest {
  @Test
  public void googlePageTest(){
    /**
      No need to create a webdriver instance!
      Selenide provides with easy to use API's that provide rich functionality.
      On a normal day with selenium, we would need to create a webdriver instance, and bind it to a browser.
      We would also need to define page elements to use them.
      Selenide removes the need to do this by wrapping up that into a singe API.
      Below, we use "open" to create the webdriver instance, and bind it to a class.
      Passing it a class, provides the shape for the instance, giving it methods and defined functionality.
     */
    GooglePage googlePage = open("http://www.google.com",GooglePage.class);


    /**
      Now that we have an instance of webdriver up and we are on our test app, Google.
      We can then search something.
      Searching for something means it will return a result.
      Therefore, we need a class to take the shape of these results.
     */
    SearchResultsPage searchResultsPage = googlePage.searchGoogle("selenide");


    /**
    Tests.
    Now that we have results, we can perform tests.
    Below, we use the searchResultsPage and query the class for expected results.
     */
    searchResultsPage.checkResultsSize(8);
    searchResultsPage.getResults().get(0).shouldHave(text("Selenide: concise UI tests in Java"));


    /**
    Use page object models and design patterns
    This example is to demo the ease of use with Selenide.
    Its important to separate out your implementation for better maintenance, easy of reading and debugging.
     */
  }

}

In Code – Get going in 3 easy steps

This project is written in Java, uses the page object model and is triggered by a BDD Cucumber feature file. Learn these terms well. 

Lets get into it:

Step 1: Define our Page Objects

The things you want to interact with on a page like:

• buttons
• lists
• labels
• text inputs

Step 2: Step Definition

Step definitions are the glue that will bring a workflow to your elements and bind them your feature file.

Here we chain our actions together and feed them input using our feature file.

Eg, the loginCuke() method:

• we open up the site in a web page using Selenide. A 1 liner which will handle a lot of the grunt of selenium behind the scenes.
• we then proceed to run the login method that will:
  • take our input username and password from the feature file and process the login method. 

Step 3: Create your feature file

Feature files are BDD scribed tests.

We write these in plain english and translate that to code…as we did above

Thats it! run your feature file and wait for the results.

You’ll see the browser opening and doing things. Screenshots are a default on failure with Selenide so you’ll have that too!

Reporting:

Reporting is a must in any project. Please have a look at my other content for more details or pursue your own.

Conclusion:

UI testing has been around for a while and is getting easier, cheaper and simpler to implement.

With the older versions selenium we had to code a lot to get a page to open, while today we can achieve this in 1 line with a very fluent api.

Write once, test 1000 times on all browsers

our tools allow us to test on all browsers and any version…. simultaneously.

A bless in the UI testing world as it allows us to drastically reduce our testing time and therefore our cost to service testing.

Writing our own frameworks gives us greater advantage in scale and capability. 

Nothing is more fore-filling than overcoming a challenge by learning, trying and failing!

Introduction

Ola! Thanks for popping in and having a squiz

Today I’ll like to showcase how we can make our browser based test faster and more efficient by making use of 

• Docker and 
• selenium grid

Docker

Why

Docker is a great resource to use as we have the ability to spin up and environment for testing and then very quickly throw it away again.

OMG why would you do that?

Well that the power and presence of docker and containers. We can spin up, tear down and re-use this resource multiple times and we should do so, without attachment, 

Docker support is amazing. there are heaps of predefined containers that just require us to pull and use instead of us having to write and maintain those scripts, environments and data.

Its like magic at your fingertips

Selenium Grid

Grid is an extension out from Selenium which give us the ability to run our tests remotely.

Lets look at some of the key benefits:

• Run tests remotely
• Run tests in different browsers with the change of a config
• Run tests in parallel – our biggest win. 
• Reduce test time and therefore the feedback cycle.

Implementation

Start up the Selenium Grid

We’ll make use of the predefined selenium-docker containers.

This setup makes use of a dockerfile which will spin up 3 environments:

• Hub
• Chrome Node
• Firefox Node

Pull the image from: https://github.com/SeleniumHQ/docker-selenium

Head on into your download dir and docker-compose up, you will see the following: 

What we want to look out for:

• The Hub starts up and publishes a url and port.
  • in our case: localhost:4444
• The chrome node started up and registered against the hub
• The firefox node started up and registered against the hub

Navigate to the grid:

In your browser, open up: http://localhost:4444/grid/console

You will see:- 

You are viewing the grid, and the child worker nodes it has available. 

Thats it! your grid is up and running –

how damn easy was that!

But we’re not done. We need to change our test application code to hit this new environment.

Implement the Hook into the grid

To open the browser we need to establish some browser capabilities to start up our browser.

These are seen as ChromeOptions(),

We need to apply these setttings so that we can start up a browser on a linux terminal with no display adapter. We set the headless option in particular for this.

We then need to point our RemoteWebDriver to the new url,

We do so by setting the  urlToRemoteWD variable, which point to the url of the grid.

Run your test

When we run our test, – 

Our test is published to the master

The master will inspect which node is free and available and will push the test to run there.

The results are fed back to the master and then fed back to our test application for reporting. 

You are ALL DONE and ready to run a battery of tests against AWS or locally, headed or headless.