Sample code for testing technology application based on Docker+Selenium Grid

Introduction to Selenium Grid

Although some new features of Selenium Grid will be described in the Selenium 4.0 version to be released in the future, there is not much official detailed documentation for your reference at present, so this book still combines the currently widely used Selenium Grid version for explanation.

As its official website describes Selenium Grid, it is an intelligent proxy server that allows Selenium tests to route commands to remote web browser instances. Its purpose is to provide an easy way to run tests in parallel on multiple machines. With Selenium Grid, a server acts as a hub that routes JSON-formatted test commands to one or more registered Grid nodes to gain access to remote browser instances. The Hub has a list of registered servers that it has access to and allows control of those instances. Selenium Grid allows us to run tests in parallel on multiple machines and centrally manage different browser versions and browser configurations.

Figure 1 Selenium Grid component structure diagram

As shown in Figure 1, you can see that Selenium Grid is mainly composed of two parts, namely: Hub and Nodes. You can use Python, Java, C# and other languages ​​to write test Selenium scripts. Each Selenium Grid has only one Hub. The client script can specify to connect to the Hub (master node or hub). The Hub receives the client script's test run request and distributes these test requests to one or more registered nodes to execute and collect the run results. There can be one or more Nodes in Selenium Grid. The machines that act as nodes do not have to have the same operating system or the same browser as the Hub or other Nodes. That is, a Node node may be running Windows operating system, and Internet Explorer is installed on the system. Another Node node may be running Linux or Mac operating system, and the browsers installed on them may be Firefox, Safari, Chrome, etc. The configuration and testing of these Node nodes depends on the compatibility tests of the operating systems and browser versions you want to perform. In actual work, please make your choice based on the test execution plan and strategy.

Selenium Grid configuration based on Docker

The relevant image files of Selenium Grid are available in Docker Hub, as shown in Figure 2.

Figure 2 Selenium Grid related image resources

Here, we use the "docker pull" command to pull down these three images respectively. The corresponding pull commands are as follows:

docker pull selenium/hub
docker pull selenium/node-chrome
docker pull selenium/node-firefox

After the image file is pulled locally, you can use the "docker images" command to view the information of the related image, as shown in Figure 3.

Figure 3 Selenium Grid related image information

Here, let's test the connectivity between the Hub and the Node nodes.

Start the Hub, as shown in Figure 4.

Figure 4 Creating and starting the hub container

Create and start the chromenode container node, as shown in Figure 5.

Figure 5 Creating and starting the chromenode container node

Create and start the firefoxnode container node, as shown in Figure 6.

Figure 6 Creating and starting the firefoxnode container node

Next, enter "http://localhost:4444/grid/console" in the address bar of the local browser, that is, open the Selenium Grid console, and the page shown in Figure 7 will appear.

Figure 7 Grid Console Information

As shown in Figure 7, the current version of Selenium Grid is 3.141.59. The two Node nodes connected to the Hub are the Linux operating system with IP 172.17.0.4 using the Firefox 75.0 browser and the Linux operating system with IP 172.17.0.3 using the Chrome 81.0.4044.92 browser. By default, the Hub node uses port 4444, and the Node node in this example uses port 5555. If port conflicts occur in the same container, you need to adjust and set other ports according to the actual situation to avoid port conflicts.

Case demonstration based on Docker+Selenium Grid

Next, I will use the Bing search case to implement compatibility testing on Chrome and Firefox browsers. What do you think after learning about Selenium, Docker, and Selenium Grid? Is it possible to complete compatibility testing based on different browsers by using Docker+Selenium Grid? Yes, that is indeed a good idea.

But what do you need to do to make your Selenium test scripts run in different browsers?

You need to make some changes to the script design. Usually, you need to specify the host and port when the script is run. The script will look like this:

import time
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
 
driver = webdriver.Remote(
    command_executor = 'http://192.168.1.102:4444/wd/hub',
    desired_capabilities = DesiredCapabilities.CHROME)
 
base_url = 'https://cn.bing.com'
driver.get(base_url)
driver.save_screenshot('chrome.png')
driver.close()

Usually when executing, you only need to specify the address of the Hub (ie: http://192.168.1.102:4444/wd/hub). The IP address of the host machine is shown in Figure 8. The Hub will automatically assign the script to the Node node for execution.

Figure 8 Host machine IP address information

- command_executor parameter: This parameter is optional and can specify a remote server URL string or a custom remote connection. The default value is "http://127.0.0.1:4444/wd/hub".

- desired_capabilities parameter: This parameter is required and can be used to configure a dictionary of requested capabilities when starting a browser session. Here we apply "DesiredCapabilities.CHROME", you can view its corresponding source code as shown below.

class DesiredCapabilities(object):
    """
    Set of default supported desired capabilities.
    Use this as a starting point for creating a desired capabilities object for
    requesting remote webdrivers for connecting to selenium server or selenium grid.
    Usage Example::
        from selenium import webdriver
        selenium_grid_url = "http://198.0.0.1:4444/wd/hub"
        # Create a desired capabilities object as a starting point.
        capabilities = DesiredCapabilities.FIREFOX.copy()
        capabilities['platform'] = "WINDOWS"
        capabilities['version'] = "10"
        # Instantiate an instance of Remote WebDriver with the desired capabilities.
        driver = webdriver.Remote(desired_capabilities=capabilities,
                                  command_executor=selenium_grid_url)
    Note: Always use '.copy()' on the DesiredCapabilities object to avoid the side
    effects of altering the Global class instance.
    """
 
    FIREFOX = {
        "browserName": "firefox",
        "acceptInsecureCerts": True,
    }
 
    INTERNETEXPLORER = {
        "browserName": "internet explorer",
        "version": "",
        "platform": "WINDOWS",
    }
 
    EDGE = {
        "browserName": "MicrosoftEdge",
        "version": "",
        "platform": "ANY"
    }
 
    CHROME = {
        "browserName": "chrome",
        "version": "",
        "platform": "ANY",
    }
 
    OPERA = {
        "browserName": "opera",
        "version": "",
        "platform": "ANY",
    }
 
    SAFARI = {
        "browserName": "safari",
        "version": "",
        "platform": "MAC",
    }
 
    HTMLUNIT = {
        "browserName": "htmlunit",
        "version": "",
        "platform": "ANY",
    }
 
    HTMLUNITWITHJS = {
        "browserName": "htmlunit",
        "version": "firefox",
        "platform": "ANY",
        "javascriptEnabled": True,
    }
 
    IPHONE = {
        "browserName": "iPhone",
        "version": "",
        "platform": "MAC",
    }
 
    IPAD = {
        "browserName": "iPad",
        "version": "",
        "platform": "MAC",
    }
 
    ANDROID = {
        "browserName": "android",
        "version": "",
        "platform": "ANDROID",
    }
 
    PHANTOMJS = {
        "browserName": "phantomjs",
        "version": "",
        "platform": "ANY",
        "javascriptEnabled": True,
    }
 
    WEBKITGTK = {
        "browserName": "MiniBrowser",
        "version": "",
        "platform": "ANY",
    }
 
    WPEWEBKIT = {
        "browserName": "MiniBrowser",
        "version": "",
        "platform": "ANY",
    }

From the source code of the DesiredCapabilities class, we can see that "DesiredCapabilities.CHROME" is a dictionary object defined by this class.

Here, the author uses a multi-threaded approach to implement Bing search services in Chrome and Firefox browsers respectively. The corresponding scripts are as follows.

Grid_Test.py file content:

from threading import Thread
from selenium import webdriver
from time import sleep,ctime
from selenium.webdriver.common.by import By
 
def Test_Bing(Host, Browser):
    caps = {'browserName': Browser}  
    driver = webdriver.Remote(command_executor=Host, desired_capabilities=caps)
    driver.get('http://www.bing.com')
    driver.find_element(By.ID,'sb_form_q').send_keys('asynchronous community')
    driver.find_element(By.ID,'sb_form_go').click()
    PicName=Browser+'_result'+'.png'
    driver.save_screenshot(PicName)
    assert ('No results related to this' not in driver.page_source)
    sleep(2)
    driver.close()
 
if __name__ == '__main__':
    pcs = {'http://192.168.1.102:4444/wd/hub': 'chrome',
             'http://localhost:4444/wd/hub': 'firefox'
             }
    threads = []
    tds=range(len(pcs))
 
    # Create thread for host, browser in pcs.items():
        t = Thread(target=Test_Bing, args=(host, browser))
        threads.append(t)
 
    # Start thread for i in tds:
        threads[i].start()
    for i in tds:
        threads[i].join()

From the script above, you can see that a function named Test_Bing() is created, which contains two parameters, namely the host and the browser. The execution intention of the function is to perform a search in the corresponding browser based on the remote server URL string and the passed-in browser name string, and the search term is "asynchronous community", take a screenshot of the execution result, the name of the screenshot is the corresponding browser name + "_result.jpg" file, and assert the search result. It should be noted that the purpose of taking a screenshot of the results here is not only to see the results, but also because when using Selenium Grid, no browser will appear during the test execution, so you cannot see the execution process. In order to prove the correctness of the results, we also need to take a screenshot to prove that it is indeed working and the execution is correct. If you want to see the interfaces of different containers during execution, you can also use VNC Viewer to connect to the corresponding container (but you need to download the corresponding selenium/node-firefox-debug and selenium/node-chrome-debug image files. The images ending with debug all have VNC servers. You can install VNC clients on your local computer to connect remotely. Port 5900 is the listening port of VNC Viewer, so a port mapping is done), as shown in Figures 9 and 10.

Figure 9 Creating and starting the Debug version of the node container

Figure 10 VNC Viewer to observe the script execution of the node container

In fact, this does not make much sense for testing work, so I will not go into too much detail.

In the main function, a dictionary containing 2 elements is defined. You can see that the author uses 2 different representations of the same address (the IP address of the host machine is 192.168.1.102), and "localhost" also means the local machine, that is, the host machine. So why not just use "192.168.1.102" or "localhost"? This is because dictionary keys are not allowed to be repeated. Next, a thread list is created, and the keys and values ​​of the pcs dictionary are used as parameters of the Test_Bing() function and added to the thread list. Then start each thread in the thread list.

Before running the script, you need to ensure that the Hub and Node containers are created and started (Note: the author uses the non-Debug version of the Node image here), as shown in Figure 11.

Figure 11 Creating and starting the Hub and Node containers

After the script is executed, two image files, “chrome_result.jpg” and “firefox_result.jpg”, will be generated, as shown in Figure 12.

Figure 12 Image file information generated after script execution

As shown in Figure 13 and Figure 14, in this compatibility test, you can see that both browsers executed the same Bing search service. Their page display, layout, and content are basically the same, but there are two small problems. The search results in the Chrome browser are "855,000 Results", while the search results in the Firefox browser are "859,000 Results", which are inconsistent. Another minor issue is that in Firefox it says "Sign in" and a login icon, but in Chrome it doesn't. Theoretically, these are two minor bugs with lower severity levels, but the author recommends that you confirm these two minor differences with your product and R&D colleagues. Product, testing, and R&D should unify and clarify requirements, and then modify the requirements or code to keep them consistent.

Figure 13 chrome_result.jpg image file information

Figure 14 firefox_result.jpg image file information

This is the end of this article about the sample code of the test technology application based on Docker+Selenium Grid. For more relevant Docker Selenium Grid test technology content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!