DEV Community: Idowu Omisola

How To Press Enter Without WebElement In Selenium Python

Idowu Omisola — Sun, 21 Jul 2024 17:34:22 +0000

The Selenium WebDriver is an indispensable testing framework with many interactive features for automating web actions. However, the standard WebDriver methods of interacting with a web page may sometimes need to be revised to test specific features.

For instance, a web page that renders content asynchronously or dynamically may not arrange responses in order. Hence, using the WebDriver directly without a wrapper might be inefficient in interacting successfully with its web elements during automation testing.
Your test scenario might also involve automating interactions such as mouse clicks, keyboard actions, and animated gestures sometimes. Leveraging the WebDriver’s *execute_script *method helps in such cases. And if your test needs to perform low-level gestures like dragging and dropping, Selenium’s ActionChains class also comes in handy as a wrapper class to aid such actions.

Selenium’s ActionChains and execute_script are handy for automating a website’s response to keyboard and mouse actions and animated cursor gestures.

In this blog, I’ll show you how to press enter without WebElement in Selenium Python using ActionChains *and *execute_script.

What are ActionChains in Selenium?

ActionChains is a built-in class in Selenium for automating low-level interaction with the DOM. It arranges actions in a queue and features mouse actions, including click events, cursor, and touch gestures. It also supports keyboard simulations for pressing the keypads. Thus, it provides ways to interact with a web page like a regular user.

Although Selenium’s ActionChains queues actions sequentially in order of programmatic arrangement, it fires them at once when executed. Hence, unlike the conventional WebDriver method, the success of the entire test step depends on each action step. Once a step fails, it invalidates the whole.

You might navigate a web page without using CSS Selectors in ActionChains. But this may be time-consuming and confusing.

ActionChains are typically easier to use if a web page handles only one action, such as filling out a focused form with a blinking cursor. Overall, ActionChains is intuitive and sensitive to component actions.

The action.send_keys(data) method; for example, automatically locates a focused form field to insert the specified information:

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
data = "omisola"
action.send_keys(data).perform()

For instance, automating a search query on a web page that loads only a search box with a blinking cursor requires the following actions:

Inputting the search term using the send_keys method.
Press the Enter key to submit the search query.

However, web interaction using the ActionChains can be complex when automating several steps that involve moving between elements to execute several actions, including clicks, gestures, sending keys, and pressing the Tab and Enter keys, among many others.
In the next section of this blog on how to press enter without WebElement in Selenium Python, we will explore pros and cons of ActionChains.

Boost Your Mobile App’s Performance! Discover Proven Strategies for Mobile Performance Testing. Increase User Satisfaction & Rankings. Get Results Fast!

Pros of the ActionChains

Here’s why the ActionChains class is handy for testing a website:

The ActionChains object stores automated actions in a queue to execute them sequentially in order of programmatic arrangement. This is helpful when you need to perform a large sequence of actions at a go.
It includes mouse functionality, such as clicking and performing gestures for drag-and-drop actions.
It simulates human keyboard actions like Tab, Shift, Enter, Ctrl, PgUp, and PgDn, among others, to navigate to any position within the DOM.

Cons of the ActionChains

Although the ActionChains class lets you test a website using an array of actions, it has some shortcomings:

Test steps depend on each other since actions are in a chain queue. Thus, once a step fails, it invalidates the entire chain, causing the test to fail without clarity about the point of failure.
ActionChains can be hard to debug since it’s hard to tell which step in the chain causes the error.

Let’s consider some use cases of each approach before we discuss how to press enter without WebElement in Selenium Python. However, we need to first inspect the web elements:

ActionChains example use cases

In this blog section on how to press enter without WebElement in Selenium Python, shown below are the snippets of basic usage examples of ActionChains:

How to create an ActionChains object:

from selenium.webdriver import Keys, ActionChains
action = ActionChains()

1. Drag and drop an element using the ActionChains.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
driver.get("https://www.lambdatest.com/selenium-playground/drag-and-drop-demo")
draggable = driver.find_element(By.ID, "draggable")
dropZone = driver.find_element(By.ID, "droppable")
action.drag_and_drop(draggable, dropZone).perform()

2. Double-click an element in ActionChains.

xoffset is an integer defining the pixel distance for left and right positions across the web page, while yoffset is an integer defining the pixel distance for vertical (up and down) movement across the web page.

The example below holds down the right mouse pad to drag the draggable to 150 pixels to the right and releases the mouse at the specified position to drop the held item:

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
draggable = driver.find_element(By.ID, "draggable")
action.drag_and_drop_by_offset(draggable, 150, 0).perform()

Perform a click event using ActionChains.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
element = driver.find_element(By.LINK_TEXT, "LambdaTest")
action.click(element).perform()
Double-click an element in ActionChains.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
element = driver.find_element(By.LINK_TEXT, "LambdaTest")
action.double_click(element).perform()

5. Right-click an element in* ActionChains *(context-click).

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
element = driver.find_element(By.LINK_TEXT, "LambdaTest")
action.context_click(element).perform()

6. Click and hold an element.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
element = driver.find_element(By.LINK_TEXT, "LambdaTest")
action.click_and_hold(element).perform()

7. Send keys and press the Enter key using the ActionChains.

Web page: https://www.lambdatest.com/selenium-playground/simple-form-demo.

Web page inspection:

This guide focuses on test automation metrics, its significance, strategies, challenges, and key test automation metrics for measuring success.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
driver.get("https://www.lambdatest.com/selenium-playground/simple-form-demo")
password = driver.find_elemnt(By.ID, "user-message")
action.send_keys(password)
action.send_keys(Keys.ENTER).perform()

8. Press the Tab key using the ActionChains.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
password = driver.find_elemnt(By.ID, "user-message")
action.send_keys(password)
action.send_keys(Keys.TAB).perform()

Perform an action on key-up or key-down in ActionChains.

action.key_down(Keys.CONTROL).send_keys('Idowu').key_up(Keys.CONTROL).perform()
Move to a specific element:

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
inputform = driver.find_element(By.ID, "user-message")
action.move_to_element(inputform)
Move the mouse relative to an element by offset.

from selenium.webdriver import Keys, ActionChains
action = ActionChains()
driver = webdriver.Chrome()
inputform = driver.find_element(By.ID, "user-message")
action.move_to_element_with_offset(inputform, 100, 200).perform()
Move the mouse to a specific location by offset.

action.move_by_offset(100, 200)

What is the execute_script method in Selenium?

The execute_script is a Selenium WebDriver method that allows the execution of JavaScript events and actions in the current window. It involves embedding pure JavaScript as a string into Python to modify the DOM.

While the execute_script method makes automation testing more flexible with browser API access, it’s easier with a knowledge of JavaScript.

Since it’s JavaScript, if you don’t want to use Selenium locators, you can use JavaScript’s document queries like getElementById *or getElementByClassName* to get web elements.

For example, the conventional locator takes the following form for locating an element by its ID:

element = driver.find_element(By.ID, element_id)

However, the execute_script method takes the following form:

element = driver.execute_script(“document.getElementById(‘user-message’);”)

In this blog on how to press enter without WebElement in Selenium Python, we’ll combine JavaScript’s querySelector and the XPath methods to interact with the web page elements.

Learn the ins and outs of test execution engines through our extensive guide, and enhance your testing workflow with automation.

Pros of the execute_script method

Here’s why you want to use the execute_script method:

Since JavaScript has access to browser APIs, the execute_script method allows you to manipulate the DOM directly. For instance, you can leverage the embedded JavaScript to scroll to a particular position on a web page, insert an element into the DOM, get the website’s domain name, or even refresh the browser.
It’s also suitable for testing applications and websites that render content asynchronously and dynamically.
Since all modern browsers support JavaScript, the execute_script method can confer better cross-browser compatibility, as you can use JavaScript to tweak events to suit the test browser.

Cons of execute_script method

JavaScript is the language of the web. So using this automation method can introduce vulnerabilities to a website.
JavaScript embedding can be hard to read, especially if you’re from a Python background with little or no knowledge of JavaScript.

execute_script example use cases

This section on press enter without WebElement in Selenium Python discusses some applications of the *execute_script *method:

Here’s the basic syntax of execute_script:

driver.execute_script(script)

Spin up an alert browser window using execute_script:

driver.execute_script(“alert(‘this is a test’);”)
Type a text into an input field:

driver.get("https://www.lambdatest.com/selenium-playground/checkbox-demo")
driver.execute_script("document.getElementById('user-message').value='Idowu paul';")
Click an element (e.g., a button):

button = driver.execute_script(“return document.getElementById(‘showInput’);”)
driver.execute_script(“arguments[0].click()”, button)
Handle a checkbox using Boolean:

driver.get(“https://www.lambdatest.com/selenium-playground/checkbox-demo")
driver.execute_script(“document.getElementById(‘isAgeSelected’).checked=true;”)

To learn more about it, you can go through our earlier blog on handling checkboxes in Selenium.

Get the domain name of a website:

domain_name = str(driver.execute_script("return document.domain;"))
print(domain_name)
Create a new element in the DOM:

driver.execute_script("var element=document.createElement('newButton');"
+"document.body.appendChild(element);")
Refresh a web page using execute_script in Selenium WebDriver:

driver.get("https://www.lambdatest.com/selenium-playground/checkbox-demo")
driver.execute_script("history.go(0)")
Get the height and width of a web page:

driver.get("https://www.lambdatest.com/selenium-playground/checkbox-demo")
page_height = str(driver.execute_script("return window.innerHeight;"))
page_width = str(driver.execute_script("return window.innerWidth;"))
print(page_height)
print(page_width)

This guide explores Digital Transformation, its benefits, goals, importance and challenges involved in Digital Transformation.

Demonstration: Using ActionChains and execute_script

In this section of our tutorial on press enter with WebElements in Selenium Python, I’ll demonstrate the test cases using the ActionChains class and the execute_script method in different code files. Both are a part of Selenium. So you don’t need to install them separately once you install Selenium.

We’ll also use the Selenium pytest module for the test execution.

Our test website is LambdaTest’s eCommerce playground.

Initially, we will showcase the process of navigating the registration page using Selenium’s *ActionChains *in a sequential manner. After understanding the functioning of the previous demonstration, we will proceed to repeat the test utilizing the *execute_script *method from Selenium WebDriver.

So this blog on how to press enter without WebElement in Selenium Python assumes you’ve already installed Python on your local machine. Our test cases in this blog use Python 3.10. You can follow pretty well using earlier versions, though.

We’ll also use VSCode for our test suite development in this blog on press enter without WebElement in Selenium Python. But you can stick to an IDE that works best for you.

Don’t miss out on thе latеst tutorials on automation tеsting! Subscribe to thе LambdaTеst YouTubе Channеl for tutorials on Sеlеnium tеsting, Playwright testing, and more

Install Dependencies

To set the ground for this automation testing, you must first install Selenium and pytest in your Python virtual environment. We’ll also mask dependencies using the environment variable (.env file). So you might want to include python-dotenv in your dependencies list.

Create a requirements.txt file in your project root directory and list the following packages:

FileName — requirements.txt

pytest
selenium
python-dotenv

Next, run the following in your command line to install the listed packages:

pip install -r requirements.txt

The dependencies install as shown:

Set up a pytest Configuration file

This blog section on press enter without WebElement in Selenium Python, we will see how to set up a pytest configuration file.

While it’s not a requirement, a pytest configuration file (pytest.ini) allows you to define more behaviors for your test environment. For instance, you can use this file to declare how you want your test to log results in the terminal or inside a log file.

This file executes before other test files since it contains the test configurations and resides in the root directory.

In this case, we’ll ignore deprecation warnings using the pytest.ini file:

FileName — pytest.ini

[pytest]
filterwarnings = ignore::DeprecationWarning

The pytest.ini file has other configuration options besides ignoring deprecation warnings. But note that it doesn’t work without the [pytest] entry point — as written above.

For instance, among other settings, you can use it to configure the command-line outputs and custom-exit test execution once the test fails n times. You can also use it to point to your settings file while testing websites developed with complex web frameworks like Django locally. You can learn more about it through this tutorial on pytest Django.

Here are a few more configuration options for pytest.ini:

Console_output_styl*e= **progress (default), **classic, or **count. Specify any of these options to customize how Pytest displays results. For example, while **progress* loads test results using percentages, count displays the number of tests executed.
faulthandler_timeout = 10; exits the test after a 10-second timeout.
log_auto_indent = Boolean; choose whether to allow auto-indentation of CLI logs.
log_cli = Boolean; specify whether or not you want to see execution logs during test executions.
*log_file *= log/log FileName.txt; write test logs into a file in your project root directory.
log_file_date_format = %Y-%m-%d %H:%M:%S; append test time and date to log files.
log_level = INFO; specify the log type.

In this article, we will delve into the fundamentals of Quality Assurance, its key principles, methodologies, and its vital role in delivering excellence.

Project Structure

This section on press enter without WebElement in Selenium Python shows the entire test suite structure:

test_directory
├─ .gitignore
├─ pytest.ini
├─ README.md
├─ settings
│  └─ Setup.py
├─ suites
│  ├─ test_reg_action_chain.py
│  └─ test_reg_js_action.py
└─ webactions
   ├─ javaScript_web_actions.py
   └─ action_chain_web_actions.py

File descriptions:

**settings/Setup.py *:* It contains the setup class for the entire test suite. All test demos share this setup.
**suites/test_reg_action_chain.py *:* Contains the ActionChain *test demo. When executed, it runs the test using the *ActionChain class.
**suites/test_reg_js_action.py *:* Holds the test execution class for the JavaScript web actions (execute_script).
**webactions/javascript_web_actions.py *:* This file contains the web page locator and the web action classes. We import and use it inside the **suites/test_reg_js_action.py **file.
**webactions/action_chain_web_action.py *:* Test suite web actions and locators that use the ActionChain are in this file. We import it into suites/test_reg_action_chain.py to use its class attributes and methods.

General Test Setup:

Here’s the setup code for the test suite.

FileName — settings/Setup.py

from selenium import webdriver
from dotenv import load_dotenv
import os
load_dotenv('.env')
LT_USERNAME = os.getenv("LT_USERNAME")
LT_ACCESS_KEY = os.getenv("LT_ACCESS_KEY")
desired_caps = {
        'LT:Options' : {
            "user" : os.getenv("LT_USERNAME"),
            "accessKey" : os.getenv("LT_ACCESS_KEY"),
            "build" : "FireTest New",
            "name" : "FireBrowser",
            "platformName" : os.getenv("test_OS")
        },
        "browserName" : "FireFox",
        "browserVersion" : "103.0",
    }
gridURL = "@hub.lambdatest.com/wd/hub">https://{}:{}@hub.lambdatest.com/wd/hub".format(LT_USERNAME, LT_ACCESS_KEY)
class Setting:    
    def __init__(self):
        self.driver = webdriver.Remote(command_executor=gridURL, desired_capabilities= desired_caps)
    def setUp(self):
        self.driver.implicitly_wait(10)
        self.driver.maximize_window()
    def tearDown(self):
        if (self.driver != None):
            print("Cleaning the test environment")
            self.driver.quit()

The above code is the Settings class for the test suite. You start by importing the required libraries and loading your grid username and access key from the environment variable file using the dotenv package.

To obtain your grid username and access key, head over to your LambdaTest Dashboard’s Builds directory. Click the Access Key button at the top right to reveal your grid details.

This detailed guide explains how to detect flaky tests, its causes, strategies to reduce flakiness and much more.

The Settings *class starts with the driver attribute. The driver attribute connects to the remote grid using the *webdriver.Remote method; this accepts the gridURL variable and the desired_capabilities dictionary as the test executor and test capability settings, respectively.

In this blog on press enter without WebElement in Selenium Python, we will generate the test capabilities from the LambdaTest Automation Capability Generator as done in this test demo.

We used Firefox version 103.0 as the test browser in this demo. The chosen OS platform is Windows 10 (loaded from the .env file as shown below).

The *setUp *method pauses the driver implicitly for DOM elements to load. It then maximizes the window once it loads.

The tearDown method cleans up the test environment and quits the browser after each test.

We only need one setup file since the entire test suite shares the *Settings *class.

As mentioned earlier, I’ll start the test demonstration using Selenium’s ActionChains. Then I’ll show you how to run similar test steps using the JavaScript (execute_script) method.

So let’s get started with the demonstrations in the following sections.

Testing with Selenium’s ActionChains

This section on press enter without WebElement in Selenium Python details the test demonstration using the ActionChains class.
We’ll start with the web actions (webactions/action_chain_web_action.py), which we’ll then import and use inside the ActionChains test runner (suites/test_reg_action_chain.py)

Let’s look at our test scenario before we begin:

Open the test website.
Press the Tab key until the mouse points to the first input field.
Fill the input fields sequentially with data.
Press the terms and conditions checkbox.
Submit the registration form.
Check for a successful registration by taking the title of the following web page.

This guide focuses on test automation metrics, its significance, strategies, challenges, and key test automation metrics for measuring success.

FileName — webactions/action_chain_web_action.py

from selenium.webdriver.common.by import By
import time
class todoLocator:
    First_Name = 'input[placeholder=\"First Name\"]'
    Last_Name = 'input[placeholder=\"Last Name\"]'
    Email = 'input[placeholder=\"E-Mail\"]'
    Phone = 'input[placeholder=\"Telephone\"]'
    Password = 'input[placeholder=\"Password\"]'
    Password_Confirm = 'input[placeholder=\"Password Confirm\"]'
    Subscribe_yes = ".//*[contains(text(), 'Yes')]"
    Agree_Yes = ".//*[contains(text(), 'I have read and agree to the')]"
    Submit_Button ='input[value=\"Continue\"]'
class registerJSWebActions(todoLocator):
    def __init__(self, driver) -> None:
        self.driver = driver
    def getWeb(self, URL):
        self.driver.get(URL)

    def getTitle(self):
        return self.driver.title    
    def inputfirstName(self, firstName):    
        first_name_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.First_Name)
            )    
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(firstName),
              first_name_field
        )     
    def inputlastName(self, lastName):    
        last_name_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Last_Name)
            ) 
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(lastName),
              last_name_field
        )
    def inputEmail(self, email):
        Email_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Email)
            ) 
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(email),
              Email_field
        )
    def inputPhone(self, phone):
        phone_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Phone)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(phone),
              phone_field
        )
    def inputPassword(self, password):
        password_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Password)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(password),
              password_field
        )

    def inputpasswordConfirm(self, password_confirm):
        password_confirm_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Password_Confirm)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(password_confirm),
              password_confirm_field
        )
    def subScribe(self):
        subscribebox = self.driver.find_element(By.XPATH, self.Subscribe_yes)
        return self.driver.execute_script("arguments[0].click()", subscribebox)
    def agreetoTerms(self):
        agree_field = self.driver.find_element(By.XPATH, self.Agree_Yes)
        return self.driver.execute_script("arguments[0].click()", agree_field)
    def submit(self):
        submit_button = self.driver.execute_script(
            "return document.querySelector('{}')".format(self.Submit_Button)
            )
        self.driver.execute_script("arguments[0].click()", submit_button)
        time.sleep(10)

While you’ll typically write ActionChains in sequence, I separated each into methods to make it more readable, reusable, and callable while executing the test runner.

Since our test needs to send data and locate elements in an action chain, we start by importing Keys, ActionChains, and By from Selenium.

The locator class (todoLocator) only defines the website header element and the terms agreement checkbox.

The registration WebAction class (registerWebActions) inherits the locator class to use its attributes. It then initializes with the WebDriver; we’ll derive this from the Settings class while instantiating this object inside the test runner file.
Next is the declaration of the driver and the action attributes; these are the driver and the ActionChains, respectively.

Next are the methods for launching the web page URL and getting its title.

Learn the ins and outs of test execution engines through our extensive guide, and enhance your testing workflow with automation.

The header element is easy to locate since most web pages have one. I included it in the locator earlier because I wanted to start tabbing from the header element, and the test needs to click a blank point on the header to begin tabbing from there.

This allows you to count the number of times your test needs to press the Tab key to point the mouse to the first form field.

Think of this as navigating a web page using your keyboard without the mouse; you might need to press the Tab key a few times to get to a particular location. We applied a similar concept to mimic a user’s interaction with a web page.

In our case, the test clicks the header elements and presses the Tab Key six times before reaching the first input field.

We’ll also intermittently press the Tab key once or twice in some places. So next, we define methods for pressing Tab once and twice. These are handy while executing these actions inside the test runner file (suites/test_reg_action_chain.py).

Next, we define functions for entering the user’s details into the form fields. As mentioned earlier, Selenium executes *ActionChains *sequentially. So Under the hood, each class method is a sequence of the previous one.

As for the terms and agreement checkbox — it needs a click action before you can submit a registration form — so we located that previously using its text content parameter with the XPath method inside the todoLocator class. Locating a web element this way doesn’t require a CSS locator since XPath finds it by the specified text.

However, multiple elements with the exact text content on the same web page can limit this method. But you can leverage XPath’s node (nth) feature to solve this problem.

Here’s how we call an action on the agreement checkbox:

Explore our comprehensive guide on GUI Testing, uncovering its vital role in software development. Learn about its different types, best practices, and steps for effective implementation to enhance your software’s user interaction.

The self.agree_yes attribute comes from the inherited locator class (todoLocator).
The form-filling actions end with the submit method for submitting the form. This only involves pressing the Enter key (Keys.Enter).

Finally, we define the action execution method (executeactionChain) to perform the declared actions inside an action chain. We achieve this using ActionChains’ action.perform method.

The implicitly_wait method is only a desired test property, not a requirement. It pauses the browser window for 10 seconds before exiting the test. You can remove it if you don’t want a pause after the test execution.

FileName — suites/test_reg_action_chain.py

import sys
sys.path.append(sys.path[0] + "/..")
from webactions.action_chain_web_action import registerWebActions
from settings.Setup import Setting
settings = Setting()
webactions = registerWebActions(settings.driver)

class TestUserReg():
    def test_user_registration(self):
        settings.setUp()
        webactions.getWeb(  "https://ecommerce-playground.lambdatest.io/index.php?route=account/register")
        title = webactions.getTitle()
        assert "Register" in title, "Todo is not in title"
        webactions.navigatetoForm()
        webactions.inputfirstName("Idowu")
        webactions.presstabOnce()
        webactions.inputlastName("Omisola")
        webactions.presstabOnce()
        webactions.inputEmail("miniTest12@gmail.com")
        webactions.presstabOnce()
        webactions.inputPhone("08044554455")
        webactions.presstabOnce()
        webactions.inputPassword("12345678")
        webactions.presstabOnce()
        webactions.inputpasswordConfirm("12345678")
        webactions.presstabTwice()
        webactions.agreetoTerms()
        webactions.presstabTwice()
        webactions.submit()
        webactions.executeactionChain()
        settings.driver.current_url
        current_title = webactions.getTitle()
        assert "Created" in current_title, "Created is not in title"
        settings.tearDown()

The code above executes the web action chains when you run the pytest command via the terminal.

First, we import the sys module and use this to append to the module system paths. Then we import the registerWebActions class from the action_chain_web_action.py*module. We instantiate this as *webactions using the driver attribute from the settings object; this allows the WebDriver to act on the test website as declared in the ActionChains.

We also import Setting from the setup module (instantiated as settings).

The TestUserReg class has only one method, test_user_registration, that executes the web action methods from the registerWebActions class.

We call the setUp method to set up the test environment and maximize the browser window. As a convention, the test starts by launching the test website.

Then we get the web page title using the getTitle method of the webactions object and assert if “Register” is in the title text.

Next are the test steps execution:

Step 1: Our test navigates to the first form field.

Step 2: Fill the form fields and press the Tab key once after filling each input field.

Looking to manage your tests more efficiently? In this blog, explore a variety of test case management tools and select the one that suits your team’s needs.

I maintained the default subscription option, which is No. So there was no need to click that since I didn’t want to subscribe. You might need to write methods to use the Left and Right keys within the action chain class to switch between Yes and No if you want your test to “Subscribe to Newsletter.”

Hence, the test presses Tab twice to skip that option and jump to the “I have read and agree to the Privacy Policy” checkbox, which requires a click action.

Step 3: “Privacy Policy” is in a separate element. So our test presses Tab twice once more to point the mouse to the Submit button. It then presses the Enter key to submit the registration form and executes this action chain by calling the executeactionChain method.

Finally, we get the current URL and assert if “Created” is in its title text to confirm whether or not our test successfully registered a user. Then we call the tearDown method of the Settings class to clean up the test environment and exit the test.

Execution of the ActionChains

Go to your project root directory and run the pytest command:

pytest

Here’s the test execution on the command line:

Our test also runs successfully on the cloud grid as shown below. Here we are using a cloud grid offered by the LambdaTest platform.

LambdaTest is a digital experience testing platform that enables developers and QA engineers to perform Selenium Python testing on over 3000+ real browsers and OS combinations. LambdaTest provides support for different Python testing frameworks to Python automation testing. In addition, you can parallelize your test execution to expedite software release cycles.

Visit our documentation to get started with Selenium Python testing

Using Selenium’s JavaScript Executor (execute_script)

In this section of this blog on press enter without WebElement in Selenium Python, now let’s see how to navigate the same web page using JavaScript embedding (execute_script method).

Let’s start with our test scenario

Open the registration page (test website).
Fill in the registration form fields using JavaScript actions (execute_script).
Click the terms and agreement checkbox using JavaScript’s click event.
Click the submit button using JavaScript’s click event.
Take the title on the following page to check for successful registration.

FileName — webactions/javaScript_web_actions.py

from selenium.webdriver.common.by import By
import time
class todoLocator:
    First_Name = 'input[placeholder=\"First Name\"]'
    Last_Name = 'input[placeholder=\"Last Name\"]'
    Email = 'input[placeholder=\"E-Mail\"]'
    Phone = 'input[placeholder=\"Telephone\"]'
    Password = 'input[placeholder=\"Password\"]'
    Password_Confirm = 'input[placeholder=\"Password Confirm\"]'
    Subscribe_yes = ".//*[contains(text(), 'Yes')]"
    Agree_Yes = ".//*[contains(text(), 'I have read and agree to the')]"
    Submit_Button ='input[value=\"Continue\"]'
class registerJSWebActions(todoLocator):
    def __init__(self, driver) -> None:
        self.driver = driver
    def getWeb(self, URL):
        self.driver.get(URL)

    def getTitle(self):
        return self.driver.title    
    def inputfirstName(self, firstName):    
        first_name_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.First_Name)
            )    
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(firstName),
              first_name_field
        )     
    def inputlastName(self, lastName):    
        last_name_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Last_Name)
            ) 
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(lastName),
              last_name_field
        )
    def inputEmail(self, email):
        Email_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Email)
            ) 
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(email),
              Email_field
        )
    def inputPhone(self, phone):
        phone_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Phone)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(phone),
              phone_field
        )
    def inputPassword(self, password):
        password_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Password)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(password),
              password_field
        )

    def inputpasswordConfirm(self, password_confirm):
        password_confirm_field = self.driver.execute_script(
            "return document.querySelector('{}');".format(self.Password_Confirm)
            )
        return self.driver.execute_script(
            "arguments[0].value='{}';".format(password_confirm),
              password_confirm_field
        )
    def subScribe(self):
        subscribebox = self.driver.find_element(By.XPATH, self.Subscribe_yes)
        return self.driver.execute_script("arguments[0].click()", subscribebox)
    def agreetoTerms(self):
        agree_field = self.driver.find_element(By.XPATH, self.Agree_Yes)
        return self.driver.execute_script("arguments[0].click()", agree_field)
    def submit(self):
        submit_button = self.driver.execute_script(
            "return document.querySelector('{}')".format(self.Submit_Button)
            )
        self.driver.execute_script("arguments[0].click()", submit_button)
        time.sleep(10)

The ultimate guide to software testing metrics: definition, types, and examples explained for informed decisions. Enhance your testing process now!

The above code defines the web actions for JavaScript embedding demonstration. It starts with the todoLocator class, whose attributes are the web element locators. However, these locators don’t require web element inspection, as they’re visibly definitive.

Although we don’t know the underlying DOM structure, we know they’re input fields with placeholders.

Thankfully, we can get these input elements using their placeholders with JavaScript’s querySelector. You’ll see how that works down the line.

We trace the “Subscribe” option and the terms checkbox by their peculiar text content using the XPath method since we’ve assumed that we don’t know anything about their elements.

For the Submit input, I wasn’t sure at first whether it was a button or an input tag. But it works with the input tag. So sticking to locating an input with a text that says, “Continue” using XPath works.

As we did earlier for the ActionChains, the registerJSWebActions class inherits the todoLocators class and its attributes and initializes with the WebDriver.

As mentioned, we’ll use JavaScript’s querySelector to pick on web elements rather than CSS Selector.

This takes the following form:

document.querySelector(element)

Thus, a typical input field as used in our test looks like this:

The first_name_field variable defines the First Name input element grabbed using the querySelector. Since the embedded JavaScript is a string, we insert the First_Name attribute (inherited from todoLocator class) using Python’s string format method.

The returned code line within this method uses JavaScript to write the required data (firstName) into the form field accordingly.

This is the convention for the other input actions.

However, the subscribe and agreetoTerms methods use XPath to locate web elements based on specified text content. These require click action. So JavaScript does that for us.

Finally, the test locates the Submit input button using the querySelector and submits the registration form using JavaScript’s click action.

FileName-suites/test_reg_js_with_actions.py

import sys
sys.path.append(sys.path[0] + "/..")
from webactions.javaScript_web_actions import registerJSWebActions
from settings.Setup import Setting
settings = Setting()
webactions = registerJSWebActions(settings.driver)
class TestUserRegWithJS():
    def test_user_registration_js(self):
        settings.setUp()
        webactions.getWeb(     "https://ecommerce-playground.lambdatest.io/index.php?route=account/register")
        title = webactions.getTitle()
        assert "Register" in title, "Todo is not in title"
        webactions.inputfirstName("Idowu")
        webactions.inputlastName("Omisola")
        webactions.inputEmail("Iminsshjsyytdsas@gmail.com")
        webactions.inputPhone("08044554455")
        webactions.inputPassword("12345678")
        webactions.inputpasswordConfirm("12345678")
        webactions.subScribe()
        webactions.agreetoTerms()
        webactions.submit()
        settings.driver.current_url
        current_title = webactions.getTitle()
        assert "Created" in current_title, "Created is not in title"
        settings.tearDown()

The above code executes the JavaScript web actions written earlier. First, we import the registerJSWebActions and Setting from their respective modules.

We then instantiate the Setting class as settings. We instantiate the r*egisterJSWebActions* class as WebActions using the driver attribute from the settings object.

The TestUserRegWithJS class holds the test execution method (test_user_registration_js).

Step 1: This starts with the test setup, website launching, and title grab with an assertion to check if the browser agent has loaded the test website successfully.

This is similar to the action chain option code.

Step 2: Next, we call the input actions as shown below:

Step 3: Click the Subscribe and Terms agreement buttons:

Step 4: Finally, click the Submit button, get the next page title, and assert whether or not the test registered the user successfully.

Step 5: Quit the browser and end the test by calling the tearDown method from the Setting class:

JavaScript (execute_script) Demo Execution

To execute the JavaScript demonstration for navigating the web without an element, cd into your project root folder from the command line and run the pytest command:

pytest

Provided the registered email address is unique, the test runs successfully, as seen via the command line:

Our demo also runs successfully on the cloud grid, as shown below:

Deep dive to learn about test automation, its uasage, types and also gain insights on how to get started with automated testing.

You can get creative with your automation testing

No cap fits it all when navigating a web page without specifying elements. While the options we’ve considered may save time in some cases, they could also be daunting for testing complex websites or executing end-to-end testing.

If web elements are available, testing a website without inspecting its DOM for CSS Selectors isn’t a best practice. It could be costly, time-consuming, and confusing. However, such a situation might cross your way as a tester. Improvise your way with the test website — regardless of the odds.

As you’ve seen in our test demos, the ActionChains class and the execute_script methods are handy to navigate a website and press enter without WebElement in Selenium Python.

We had to go through some logical trials to navigate the test web page and complete the automation testing.

Frequently Asked Questions (FAQs)

What is the command for Enter text in Selenium?

In Selenium, the command for entering text into an input field is the send_keys() method. Here’s an example of how to use it:

element = driver.find_element_by_id("myInput")
element.send_keys("Hello, World!")

In this example, driver refers to the WebDriver instance, and find_element_by_id(“myInput”) is used to locate the input field element on the webpage. The send_keys() method is then called on the element to enter the desired text, which in this case is “Hello, World!”.

You can replace “myInput” with the appropriate locator method (find_element_by_name, find_element_by_xpath, find_element_by_css_selector, etc.) based on how you want to locate the element.

After using send_keys() to enter the text, you can interact with other elements or simulate additional actions as needed.

How To Check If An Element Exists In Python Selenium

Idowu Omisola — Fri, 03 Nov 2023 07:33:25 +0000

The content of a dynamic web page is changeable, which can change with each request or session as the database is updated. This can lead to automation test failures when using tools like Selenium. These changes alter the DOM layouts and the attributes of web elements, making it difficult for automation scripts to locate specific elements based on their previous specifications.

Selenium’s built-in mechanisms, such as NoSuchElementException, are not always sufficient to handle these dynamic changes, and they may not account for delays caused by asynchronous calls or network issues.

To address this challenge to check if an element exists in Python Selenium while locating web elements, you can implement a solution that fits if an element exists before interacting with it. This approach helps in tracking and adapting to changes in the DOM content.

While Selenium’s *NoSuchElementException *can be used for this purpose, it may need more flexibility and specificity. A more effective solution would involve creating custom methods or functions that consider checking if an element exists in Python Selenium, adapting to changes, and handling potential delays due to asynchronous calls or network glitches. This ensures more robust and adaptable automation tests on dynamic web pages.

In this blog, we will delve into the essential skill of checking if an element exists in Python Selenium during automation testing. We will cover the significance of this skill and provide a step-by-step guide on how to implement custom methods and functions to accomplish this task effectively.

Binary to Decimal Converter is a tool that converts binary numbers into their equivalent decimal form. Simply enter a binary number and let this converter do it for you.

Why check if an element exists in Python Selenium?

When your UI automation test encounters a failure, a crucial strategy is to validate if the targetted web elements are present and ready for interaction. However, a more effective and sustainable approach involves checks right from the start rather than relying on debugging when issues arise.

By involving these checks in the initial stages, you can proactively deal with potential errors and set a strong foundation for reliable automation testing.

In this section, we will delve into the significance of this proactive approach, exploring why it’s essential and how to implement it effectively. This strategy ensures smoother and more robust testing experiences, ultimately saving time and resources in the long run.

Here are some reasons to check if an element exists in Python Selenium during test automation:

Handling dynamic web content

Handling dynamic web content in automation testing is a crucial skill. When web pages change frequently or elements get reshuffled in the Document Object Model(DOM) layout, causing the automation tests to break, this is even common while automating shadow web elements.

To address this, testers use various strategies like switching to relative XPath locators, locating the web elements with multiple attributes, or finding elements by their indexes.

Other locators like ID, className, CSSSelector, and more can come in handy based on situations and needs when locating a web element to check if an element exists in Python Selenium.

Explore this comprehensive blog on Selenium locators to enhance your element identification skills. This blog provides valuable insights, tips, and best practices to help you become a pro at locating web elements.

By proactively checking if an element exists in Python Selenium and element visibility, testers can adapt their tests to handle these changes, making their automation more robust and reliable.

This approach helps with smoother testing experiences and prevents potential bugs from leaking into production. Handling dynamic web content is essential for successful automation testing.

Early bug detection

Besides web content dynamism, a web element may be present, but it can be slow to respond inactive due to external conditions like network speed.

Checking if an element exists in Python Selenium during test automation helps you identify the direct cause of a test failure. It prevents potential bugs from leaking into production.

A tool that converts decimal to octal representation. Input a decimal number and click ‘Convert to Octal’ to get the result in seconds!

Reduce test flakiness

If a desired web element is not rendering correctly or missing, it might indicate a bug in the UI or the test suite. Checking the presence and visibility of the desired web element helps identify where updates may be needed in either the UI or the test suite.

It helps verify that a web element is visible and responsive to user interactions before moving to further test steps. It also helps verify if your UI test needs to include a significant action. This might involve ensuring the target web element exists and is visible before any interaction is performed.

To overcome flaky tests and unexpected failures, explore this blog on how to overcome flaky tests and unexpected failures. This resource provides valuable insights and strategies to enhance the reliability of your test automation.

Different techniques for checking if an element exists in Python Selenium

Techniques like counting the presence of the target element, utilizing boolean assertions along with expected_conditions, or using Selenium’s built-in exception handling can be a great help while checking if an element exists in Python Selenium.

Handling exceptions in Selenium can sometimes be tricky and challenging when dealing with concepts like dynamic web elements. To know more about what types of built-in exceptions Selenium provides, explore this blog on how to handle errors and exceptions in Selenium Python.

In the further section, we will see examples demonstrating the different techniques to check if an element exists in Python Selenium using the count() method and is_displayed, is_enabled with *expected_conditions*.

Before jumping to the demonstration, let’s look into the prerequisites we need to set up, from choosing the coding language testing framework to finalizing the IDE.

Need to convert your hexadecimal code to binary quickly? Our hex to binary converter makes it simple, fast, and free.

In this case, I will use Python version 3.10.6, and the IDE will be VS Code. You’ll also need to install the following packages:

pytest
Selenium
python-dotenv

To run our tests, we will use pytest as a test runner and Selenium as the framework that provides drivers and interactive methods to automate the test.

Now, create a file and name it requirements.txt. This file must be made under your project root folder as shown:

Filename: *requirements.txt*

pytest
selenium>=4.6.0
python-dotenv

Now, to install the dependencies, run the following command:

pip install -r requirements.txt

These dependencies get installed into the text file you created, that is, requirement.txt

In this case, we will use the dotenv package to mask secret variables, including your grid username and access key.

Using the pytest framework for running Python-based automation? Check out our blog on pytest tutorial. Run your test suites in parallel across multiple browsers and operating systems for complete test coverage.

Subscribe to the LambdaTest YouTube channel for more videos on Parallel testing and Selenium testing and to enhance your testing experience!

Now that everything is set up, let’s look into the technique.

Need to convert CSV to JSON? Try our free CSV to JSON converter tool to convert your CSV files to JSON format. Simple and easy to use. Try it now for free!

Using the count() technique

In this technique, we add the desired web element to a random list using a list-supported Selenium selector. Then, we count how many web elements are in that list. The resulting list remains empty if the web element is absent in the DOM.

In the following example, we’ll test a selection action from a dropdown.

Example: Select action from drop-down.

Action: First, we will check if an element exists in the dropdown before taking the action. We will check if the test has selected the expected option.

But before performing the action, we need to identify the element like ID or XPath that can help us interact with the UI.

Locating element using ID

I will perform actions on the Select Options box present on the LambdaTest Demo site using Python Selenium in this example.

But before performing any action on the Select Options button, we must find the element using any locator. In this case, I will use IDs as IDs are considered unique.
So, let’s find the element ID in the following steps:

Visit the LambdaTest Dropdown demo site.

Right-click on the web page and click on Inspect.

The developer panel will appear. Now, hover over the Select Options box and get its ID.

The ID of the Select Options box is select-demo.

Great, now that you have the element ID, let’s proceed with the other actions, like importing Selenium file libraries, invoking Chrome Driver, maximizing the browser, and more in our test script.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import Select



driver = webdriver.Chrome()

class TestSelection():


    def should_select_text(self):
        drop_down_button = "select-demo"
        selected_value = "selected-value"
        url = "https://www.lambdatest.com/selenium-playground/select-dropdown-demo"
        driver.maximize_window()
        driver.get(url)
        elements = driver.find_elements(By.ID, drop_down_button)
        assert len(elements)>0, "The element does not exist"
        drop_down = Select(driver.find_element(By.ID, drop_down_button))
        selected = driver.find_element(By.CLASS_NAME, selected_value)
        drop_down.select_by_visible_text("Sunday")

        assert "Sunday" in selected.text, "The expected day not selected"
        print(selected.text)
        driver.quit()

should_select_text_from_dropdown = TestSelection()

should_select_text_from_dropdown.should_select_text()

Great, now that you have the element ID, let’s proceed with the other actions, like importing Selenium file libraries, invoking Chrome Driver, maximizing the browser, and more in our test script.

Looking to convert binary to hex? Convert binary numbers to hex with ease using our free online Binary to Hex Converter tool. Perfect for developers and coders.

Before we see the outcome, let us understand the code in the following steps:

Code Walkthrough:

Import statements

Importing all necessary Selenium libraries and related modules.

Creating a *WebDriver *instance

This line initializes a new instance of the Chrome WebDriver, which will be used for automation.

Defining a test class

The code defines a Python class named *TestSelection *to encapsulate the test methods.

Test method *should_select_text*

This method is defined within the TestSelection class. It performs the following steps:

Assigning element identifiers: These variables store the IDs of the dropdown element and the selected value element on a web page.

Setting the URL: The web page URL to be tested is stored in the URL variable.

Maximizing the browser window: This command maximizes the browser window.

Opening the web page: The WebDriver navigates to the specified URL.

Locating the dropdown element: It attempts to locate elements on the web page using the By.ID method. If any element with the specified ID is found, it is stored in the elements variable.

Assertion for element existence: This line checks if the *elements *list is not empty, indicating that the dropdown element exists on the page. If the element is not found, it raises an assertion error.

Interacting with the dropdown: The code locates the dropdown element using driver.find_element and creates a Select object.

Locating the selected value element: The code locates the element displaying the desired value.

Selecting an option from the dropdown: It selects Sunday from the dropdown using the select_by_visible_text method.

Assertion for selected value: This line verifies that the selected text matches “Sunday” and raises an assertion error if it does not.

Printing the selected text: Finally, the code prints the selected day to the console.

Quitting the WebDriver: The *WebDriver *is closed to end the automation session.

Creating an instance of the test class and executing the test

An instance of the TestSelection class is made, and the should_select_text method is called to execute the test.

To summarize the code, it conducts UI automation, selecting a day from a web page’s dropdown, verifying the selected value, and displaying it in the console. Additionally, it includes error handling through assertions and checking if an element exists in Python Selenium.

Result

Let’s look into the other technique, which can make checking if an element exists in Python Selenium easier.

Convert your JSON files to CSV format in seconds with our easy-to-use JSON to CSV Converter. It’s fast, reliable, and user-friendly, making data conversion simple.

Using is_displayed() and is_enabled() with expected_conditions

Before we see how we can use is_displayed and is_enabled with expected_conditions, we will first understand the basics of is_displayed and is_enabled methods in Selenium.

Is_displayed(): The is_displayed() method checks if an element on a web page is visible to the user. If the element is visual, it returns true; else, it returns false.
Is_enabled(): The is_enabled() method checks if the element is interactable. If the element is not interactable, it returns false; else, it returns true.

When automation scripts fail due to an element not being clickable or if the element is hidden behind another element, using *is_displayed() *can be helpful. Learn more on how to use *isDisplayed() *in Selenium WebDriver.

Now that we have a good glance at the is_displayed() *and *is_enabled() methods, let’s understand what *expected_conditions *are.

expected_conditions: In Selenium, expected_conditions *provides methods to check various pointers of web elements such as presence, visibility, activeness, and clickability. It means you can use *expected_conditions to wait for a web element to be visible or active before the user can interact.

In addition, using expected_conditions is an add-on to your element validation by verifying if the web element is available for interaction using the is_displayed and is_enabled methods. These methods return a Boolean value, which helps to ensure that the web element is ready for interaction.

element = driver.find_element_by_name("sub_activate")
print element.is_enabled()
print(element.is_displayed)

This is an alternative method called custom error message, which you can use instead of expected_conditions. This custom error message allows you to manage missing elements by printing them when they are not found.

Let’s understand this custom error message better with an example. We will consider the previous example using these methods:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import Select
from selenium.webdriver.support import expected_conditions as EC
from selenium.common.exceptions import NoSuchElementException

driver = webdriver.Chrome()

class TestSelection():
    def should_select_text(self):

        drop_down_button = "select-demo"
        selected_value = "selected-value"
        url = "https://www.lambdatest.com/selenium-playground/select-dropdown-demo"

        driver.implicitly_wait(10)
        driver.maximize_window()
        driver.get(url)

        element_present = False
        try:
            target_element = driver.find_element(By.ID, drop_down_button)
            element_present = EC.presence_of_element_located((By.ID, drop_down_button))(driver)
        except:
            pass
        assert element_present, "element not found"

        assert target_element.is_displayed(), "The element is not visible"
        assert target_element.is_enabled(), "Element is visible but disabled"

        drop_down = Select(target_element)
        selected = driver.find_element(By.CLASS_NAME, selected_value)
        drop_down.select_by_visible_text("Sunday")

        assert "Sunday" in selected.text, "The expected day not selected"
        print(f"selected text: {selected.text}, Test status: Passed")       
        driver.quit()

should_select_text_from_dropdown = TestSelection()

should_select_text_from_dropdown.should_select_text()

Code Walkthrough

Import statements

Importing all necessary Selenium libraries and related modules.

Creating a *WebDriver *instance

This line initializes a new instance of the Chrome WebDriver, which will be used for automation.

Defining a test class

The code defines a Python class named TestSelection to encapsulate the test methods.

Test method *should_select_text*

This method is defined within the TestSelection class.

Web element IDs and URL

Web element IDs and the web page URL to be tested are defined.

Driver configuration and navigation

The driver is configured with a 10-second implicit wait, the browser window is maximized, and the web page is loaded.

In this case, I have used implicit wait, the default wait function provided by Selenium. Implicit wait methods are applied globally; you can add this once in your code, and it applies to all the web elements specified within a script throughout the entire WebDriver instance. To know more about Selenium waits, explore this blog on types of waits in Selenium, get valuable insights on holds, and learn how and when to use them.
Check for element presence

In this code section, we will check if an element exists in Python Selenium.

Check for element presence

In this code section, we will check if an element exists in Python Selenium.

A variable element_present is initialized as false.
The code attempts to find the target_element using its ID and checks its presence using expected_conditions. Any NoSuchElementException exceptions are handled in a try-except block.

Use our random string generator to create random strings of any length and character set. Input the length of string and get multiple random strings in seconds!

Assert element presence

An assertion is made to verify the existence of the target_element, and a custom error message is displayed if it’s not found.

Check visibility and enablement

Assertions are made to check if the target_element is displayed and enabled.

Dropdown selection

In this code section, we will select the dropdown option.

A Select object is created for the target_element to work with dropdowns.
The selected element is found using its class name.
The “Sunday” option is selected from the dropdown.

Assert selected value

assert Sunday is selected.text. The expected day is not selected.

An assertion is made to ensure that “Sunday” is in the selected element’s text.

Print results and quit

The selected text and a Test status: Passed message are printed. The WebDriver instance is quit to end the test.

Result

You get the following command-line output:

If true, the target_element satisfies all conditions. Hence, the test runs and passes as shown.

Use our free online Random Word Generator tool to create unique and random list of words with a click. Just input the words limit and let our tool do the rest.

Using Selenium’s built-in exception

The Selenium built-in exception catches a missing element error during automation test execution. This approach involves the use of the NoSuchElementException *exception class of Selenium.
If the test code in the try block fails, Selenium executes the exception, stating clearly that an element is missing from the DOM.
Relying solely on the *NoSuchElementException exception method can lead to incorrect failure, especially with dynamic elements or those with delayed loading. This approach can occasionally be misleading as it may trigger exceptions for dynamically generated web elements temporarily inaccessible to the driver.

Below is the output generated when the web element could not locate and interact.

To understand this better, let’s take an example.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import Select
from selenium.common.exceptions import NoSuchElementException

driver = webdriver.Chrome()

class TestSelection(Setup):
    def should_select_text(self):
        try:  
            drop_down_button = "select-demo"
            selected_value = "selected-value"
            url = "https://www.lambdatest.com/selenium-playground/select-dropdown-demo"
            driver.maximize_window()
            driver.get(url)
            target_element = driver.find_element(By.ID, drop_down_button)
            drop_down = Select(target_element)
            selected = driver.find_element(By.CLASS_NAME, selected_value)
            drop_down.select_by_visible_text("Sunday")

            assert "Sunday" in selected.text, "The expected day not selected"

            driver.quit()
        except NoSuchElementException as e:
            driver.quit()
            print(e)

should_select_text_from_dropdown = TestSelection()

should_select_text_from_dropdown.should_select_text()

The test code above masks the missing element errors for any selector using the NoSuchElementException exception. If any of the selected web elements are missing from the DOM, this method prompts Selenium to return an exception and quit the test.

Dealing with dynamic elements, implementing custom error handling, and managing potential false test failures during Selenium automation testing can be challenging. Inconsistent test results caused by dynamic web content and tests executed locally may lead to development delays.

Need to generate random text based on a regular expression for testing and generating sample data? Use our online tool to create random data from RegEx.

Using cloud platforms

Making use of a cloud-based service like LambdaTest can be proven beneficial. LambdaTest is an AI-powered test orchestration and execution platform that lets you run manual and automated tests at scale with over 3000+ real devices, browsers, and OS combinations.

Along with web automation, LambdaTest also provides a mobile device lab, which allows you to run tests on mobile devices, making it a complete solution for mobile app testing.

It provides a wide range of real browsers and operating systems for comprehensive test coverage, ensuring that dynamic elements and web content variations are handled effectively.

With cloud-based testing, developers can overcome inconsistencies caused by element readiness, reduce false test failures, and streamline the testing process. LambdaTest empowers teams to detect and address issues early in the development cycle, ultimately enhancing the reliability and quality of web applications.

How to check if an element exists in Python Selenium on LambdaTest?

We’ll use the LambdaTest eCommerce playground to demonstrate how to check if an element exists and run the test via the Selenium Grid using Python and pytest to run the test suite. Let’s begin with the steps to set up to run our test over LambdaTest.

Step 1: Create a LambdaTest account.

Step 2: Get your Username and Access Key by going to your Profile avatar from the LambdaTest dashboard and selecting Account Settings from the list of options.

**Step 3: **Copy your Username and Access Key from the Password and Security tab.

Step 4: Generate Capabilities containing details like your desired browser and its various operating systems. Generate your LambdaTest Capabilities Generator as per your requirement.

Step 5: Now that you have both the Username, Access key, and capabilities copied, all you need to do is paste it on your test script.

Having details collected from the LambdaTest platform, all you need to do is paste it accordingly into your test script; let’s cover each step in the following steps.

Need realistic test data? Use our free online Test Data Generator tool to create realistic data for your testing needs. Get started now and save time and effort.

Project setup

We must set up a few things before implementing the code with the LambdaTest platform. Let’s examine the steps individually.

1. Inspecting element: First, inspect the target web page using Chrome’s Inspect tool.

2. Project structure: Let’s take a look at the project structure:

checkElementExists
├─ .env
├─ .gitignore
├─ examples
│  ├─ dropdown_exception.py
│  ├─ dropdown_using_count.py
│  └─ dropdown_using_display_enabled.py
├─ requirements.txt
├─ setup
│  └─ setup.py
└─ testsuites
   └─ test_e_commerce.py

3. VS Code: Below is the test suite structure inside VS Code. The *examples *folder contains the test examples.

Use case

The test scenario is simple. It first hovers over a product and then clicks the heart icon once visible and active to add the selected item to the wishlist. We chose this test scenario because the wishlist icon appears dynamically on mouse hover.

Here’s a breakdown of the test steps:

Test Scenario

Step 1: Open the target URL.
Step 2: Scroll the target item into view and set the mouse on it.
Step 3: Check for the web element’s existence using expected_conditions.
Step 4: Check if the target web element is active and enabled.
Step 5: Click the wishlist icon dynamically.

The test setup is inside the setup/setup.py file, while the testsuites directory contains the test execution file.

from selenium import webdriver
from dotenv import load_dotenv
import os
load_dotenv('.env')
LT_USERNAME = os.getenv("LT_USERNAME")
LT_ACCESS_KEY = os.getenv("LT_ACCESS_KEY")

options = webdriver.ChromeOptions()
options.browser_version = "latest"
options.platform_name = "Windows 10"
lt_options = {}
lt_options["username"] = os.getenv("LT_USERNAME")
lt_options["accessKey"] = os.getenv("LT_ACCESS_KEY")
lt_options["build"] = "e-commerce and dropdown use cases"
lt_options["project"] = "Elements Check Tests"
lt_options["name"] = "E-commerce and dropdown tests"
lt_options["console"] = "error"
lt_options["w3c"] = True
lt_options["plugin"] = "python-python"
options.set_capability('LT:Options', lt_options)

gridURL = "@hub.lambdatest.com/wd/hub">https://{}:{}@hub.lambdatest.com/wd/hub".format(LT_USERNAME, LT_ACCESS_KEY)
class Setting:    
    def __init__(self):
        self.driver = webdriver.Remote(command_executor=gridURL, options= options)
    def setUp(self):
        self.driver.implicitly_wait(10)
        self.driver.maximize_window()  
    def tearDown(self):
        if (self.driver != None):
            self.driver.quit()

Code Walkthrough

Step 1: We import the webdriver package from Selenium. It allows you to configure the browser and add the desired capabilities. We also import Python’s dotenv and the os package to mask and read environment variables from the .env file.

Step 2: Next is an instantiation of the dotenv package and declaration of the LamdaTest grid username and access key.

Step 3: We instantiate a ChromeOptions object as an option. Then, we declared the browser version and platform name using the options object. The WebDriver will use these selections to set up the Chrome browser during the test execution.

Step 4: The lt_options is an empty dictionary extended with the test capabilities.

Step 5: Next, we set these capabilities and add them to ChromeOptions using the set_capability method.

Step 6: We set the cloud grid URL to include our grid username and access key.

Generate cryptographically secure and unique random bytes with our Random Byte Generator secure for your project. Give it a try today!

Step 7: The Setting class’s init function defines the driver attribute. It accepts the pre-defined options and sets the grid URL as the test executor using the webdriver’s remote method.

Step 8: Finally, we define the setUp and tearDown methods to maximize the browser window and quit the test.

Now, let’s go through the test executor file.

Filename — testsuite/test_e_commerce.py

import sys
sys.path.append(sys.path[0] + "/..")
from setup.setup import Setting
from selenium.webdriver.common.by import By
from selenium.webdriver import ActionChains
from selenium.webdriver.support import expected_conditions as EC

set_up = Setting()

class Selectors:
    item = "//img[@title='Apple Cinema 30{}']".format('"')
    wish_list = "wishlist-42"
    url = "https://ecommerce-playground.lambdatest.io/"
    action = ActionChains(set_up.driver)

class TestBuy(Selectors):    
    def test_add_item_to_wish_list(self):
        set_up.setUp()
        set_up.driver.get(self.url)
        item = set_up.driver.find_element(By.XPATH, self.item)
        set_up.driver.execute_script("arguments[0].scrollIntoView();", item)
        self.action.move_to_element(item).perform()

        element_present = False
        try:
            element_present = EC.presence_of_element_located((By.CLASS_NAME, self.wish_list))(set_up.driver)
        except:
            pass
        assert element_present, "element not found"

        wish_list = set_up.driver.find_element(By.CLASS_NAME, self.wish_list)
        assert wish_list.is_displayed(), "wishlist element not visible"
        assert wish_list.is_enabled(), "wishlist element is inactive"

      set_up.driver.execute_script("arguments[0].click();", wish_list)

        set_up.driver.implicitly_wait(10)

        set_up.tearDown()

Code Walkthrough

Step 1: We start the above code by appending the file path and importing the required modules. We import the Setting class from the setup folder to use the driver attribute, which contains the browser options and capabilities for the test suite. We also import ActionChains and expected_conditions.

Step 2: Using the ActionChain object, we can dynamically interact with a web element and perform keyboard actions and mouse events like scrolling and hovering. As shown earlier, expected_conditions lets you check if the target web element exists.

Step 3: Next, we instantiate the Setting class as set_up. Then, we declare the DOM selectors inside the Selectors class.

This class also attributes the target URL and instantiates the ActionChains using the driver attribute from Setting. It also contains the locators for the target web elements.
The item attribute is the product’s locator, while the wish_list attribute is the heart icon locator.

Step 4: The TestBuy class is the test runner class. This class inherits the Selectors class to use its attributes. This class contains only one test method (test_add_item_to_wish_list), which starts by calling the setUp method of the Setting class to maximize the browser window.

Next is executing our test steps:

Step 5: The test opens the target URL using the Selenium web driver’s get method.

Before moving to the next step, we obtained the product element using Selenium’s XPath attribute.

Step 6: Use the scrollIntoView method in JavaScript to scroll the target item into view using Selenium’s execute_script. Then, set the mouse upon it using the ActionChain object. This initiates a hover action that makes the wishlist icon visible to a user. The perform method ensures that the ActionChains run.

Step 7: Check for the web element’s existence using expected_conditions. We implement this using the try/except block. We use a wildcard except to pass possible errors since we don’t want Selenium to throw the built-in exception.

The set_up.driver call ensures the WebDriver gets the browser session for the wish_list element.

Once we assert that the wish_list element exists, we obtain it from the DOM using the inherited locator and querying it before the check might result in failing the test.

Step 8: Check if the target web element is active and enabled using the is_displayed and is_enabled methods.

Step 9: Click the wishlist icon dynamically using Selenium’s execute_script method. This method allows you to execute JavaScript inside Python with Selenium. The execute_script is ideal here, as the UI renders the wish_list element dynamically.

To know more on how to use JavaScript executor, explore this blog on how to use JavaScript executor in Selenium WebDriver.

Step 10: Finally, we call the set_up.tearDown to quit the browser and end the test.

Result

To run the test suite, open your command line to your test root folder and run the pytest command as shown.

pytest

The test runs in the command line, as shown below.

Below is the automation test execution on the Selenium cloud grid:

Looking for a unique username? Generate usernames with our Random Username Generator! Quick, easy, and fun.

Conclusion

In automation testing, it’s common to overlook the need for element existence checks. However, it’s important to remember that web elements are only sometimes readily visible. Incorporating this validation into your testing approach is crucial to keep your test suite aligned with the ever-changing software.

In this blog, we’ve explored various practical methods for checking if an element exists in Python Selenium. Our initial examples and test demonstrations provide simple, effective solutions to strengthen your test strategies. By using these approaches, you’ll improve the reliability of your automation tests and ensure that your software remains consistent, even when dealing with dynamic web elements.

Frequently Asked Questions (FAQs)

How to check if the element is visible in Python Selenium?

Use is_displayed() method. It returns True if the element is visible on the web page and False if not.

How do you verify dynamic elements in Selenium?

Use explicit waits in Selenium to ensure that the element we are looking for is available before we interact with it.

How do you find hidden elements in Python Selenium?

Hidden elements exist in the webpage’s source code but are not visible to users when they view the page. You can locate these hidden elements in Selenium by using attributes such as class name or ID. It’s important to note that even if you interact with these hidden elements using Selenium, these interactions may not produce any visible changes on the webpage that a user can see.

Pytest Django Tutorial: Testing Your Django Apps With Selenium Pytest

Idowu Omisola — Thu, 13 Apr 2023 07:49:34 +0000

Django reduces the development complexities of large-scale websites. But when developing a website with Django, UI automation testing is as essential as unit testing. Even if your team operates a CI/CD pipeline, you want to ensure you catch bugs earlier and deliver a tested build to the production environment. Although Django’s built-in test client provides a dummy browser for functional testing, it has many limitations.

Selenium overcomes these limitations and comes to mind when testing the template structure, user-DOM interaction, and JavaScript responsiveness. However, for fast, scalable, and measurable Django automation UI testing, a combination of pytest and Selenium gives an excellent result.

As for pytest, it has many valuable built-in features and plugins, making it an ideal testing tool for heavy-duty web frameworks. Thankfully, Django supports pytest and Selenium.

This pytest Django tutorial will teach you how to test your locally hosted Django website on a cloud grid using Selenium and Python. You’ll also see how you can repeat this test in a live version of your Django website.

Test your native, hybrid, and web apps across all legacy and latest mobile operating systems on the most powerful Android emulator online.

Benefits of using pytest for Django automated testing

Pytest has some features that make it an ideal Django testing tool. While you might also use the unittest module for Python automation testing, pytest makes your test easy to read and supports parameterized testing.

Below are more benefits of using this framework for pytest Django automation testing:

Parameterization

Pytest allows you to parameterize your test, simplifying the test class or function and eliminating code chunks.

Fixtures

Pytest’s fixtures are some of its most valuable features. They help you to manage the test data and separate test code from dependencies. For example, pytest fixtures can be handy for interacting with the database and creating users in a Django app.

Support for third-party and built-in plugins

Its support for many third-party and built-in plugins makes it a versatile tool for automation and Python unit testing. Some examples of plugins that work seamlessly with pytest include coverage.py and pytest-BDD for code coverage and behavior-driven tests, respectively

Support for other testing libraries

Pytest works seamlessly with other testing libraries, including unittest for unit testing and Selenium for UI automated testing.

Easy Assertions

Unlike unittest, which uses several assertion types, pytest validates expected results using only the assert keyword.

Django testing support

With the help of the pytest-django library, pytest provides full support for Django UI automation testing and unit testing.

Detail-oriented

Pytest provides detailed test information, including the test timeframe and the number of test runs.

What are pytest fixtures?

We’ll store the admin registration information for our test using pytest fixtures in this pytest Django tutorial.

So what are pytest fixtures?

Pytest fixtures are custom functions that allow you to separate test data and dependencies from the test suite. Fixtures are reusable, making the test code less complex. While they might present limitations in some use cases, they’re customizable and can work in different capacities.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated browser testing, Selenium testing, Cypress E2E testing, CI/CD, and more.

You can convert a function into a pytest fixture by adding a fixture decorator (@ pytest .fixture), which accepts an optional scope keyword argument. Pytest fixtures even pair seamlessly with Selenium for automated testing.

For example, consider testing a website if it has a particular string in its title. You can separate the test string from the function that gets the website’s title using the pytest fixture, as shown below.

from selenium import webdriver

import pytest

@pytest.fixture
def webPageTitle():
    driver = webdriver.Chrome()
    driver.get("https://www.lambdatest.com/automation-demos")
    return driver.title

@pytest.fixture
def titleString():
    return "Selenium"


def test_string_in_webPage_title(webPageTitle, titleString):
   assert titleString in webPageTitle

Running the above test using the pytest command runs as shown.

Mobile emulators online from LambdaTest allows you to seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices.

Holding Test Fixtures: What is the conftest.py file?

The conftest.py file connects your fixtures automatically with your test suite without explicitly importing them. So while fixtures are optional and may not be applicable in all test types, pytest looks for them inside conftest.py.

By default, pytest only recognizes fixtures written within the same module. But the conftest.py file allows you to use them across your test directory.

When you write fixtures in the conftest.py file, you don’t need to import them explicitly in your test. Pytest automatically recognizes all functions (with the fixture decorator) inside conftest.py as fixtures.

While pytest maps fixtures in conftest.py automatically, you can’t call them directly in your test modules. You use another pytest fixture to handle the main one indirectly to use it in your test class or function.

For instance, we can rearrange the previous example above by isolating the fixtures from the test function. This also allows us to isolate test dependencies.

To achieve this, create a new test folder. Make a new conftest.py and a test.py file inside that folder. Then separate the test concerns as shown.

from selenium import webdriver

import pytest

@pytest.fixture
def webPage():
    driver = webdriver.Chrome()
    driver.get("https://www.lambdatest.com/automation-demos")
    return driver.title

@pytest.fixture
def titleString():
    return "Selenium"

def test_string_in_webPage_title(webPage, titleString): assert titleString in webPage

def test_string_in_webPage_title(webPage, titleString):
   assert titleString in webPage

As seen in the example above, you don’t need to import the fixture explicitly into test.py to use them.

Open your terminal to your test folder and run the following command:

pytest test.py

The test runs successfully, as shown below.

Parameterized Fixtures

Fixtures are also parameterizable, allowing you to execute several tests in one test function. Let’s take a quick look at its usage in the following example.

In this section of the pytest Django tutorial, you will visit two websites and check if the action is successful by asserting that a particular string is present in each web title.

You could write the test for each website as a boilerplate, as shown:

from selenium import webdriver

driver = webdriver.Chrome()

first_website = "https://www.lambdatest.com/automation-demos"
second_website = "https://www.lambdatest.com"

def test_first_web_page():
    driver.get("https://www.lambdatest.com/automation-demos")
    assert "Selenium" in driver.title, "Selenium should be in the title"

def test_second_web_page():
    driver.get("https://www.lambdatest.com")
    assert "LambdaTest" in driver.title, "LambdaTest should be in the title"

The two tests pass, as shown below.

But we can eliminate this boilerplate by passing the websites as parameters in our test function. Hence, a single test function validates the result instead of the separate units.

When parameterized, the code becomes the following.

import pytest

from selenium import webdriver

driver = webdriver.Chrome()

first_website = "https://www.lambdatest.com/automation-demos"
second_website = "https://www.lambdatest.com"

@pytest.mark.parametrize("allWebsites", [first_website, second_website])
def test_all_customer_outputs(allWebsites):
   driver.get(allWebsites)
   assert "Selenium" and "LambdaTest" in driver.title, "Selenium and LambdaTest must be in titles"

The test visits each website in the list and validates the input data, as shown.

However, while a parameterized fixture shortens the code, its limitation is that you might not have the flexibility of customizing the error message for each expected output, as done in the previous chunked code above.

Setting up pytest Django Project

If you don’t already have a running pytest Django project, you can set it up using the brief explanation below if you’ve not done so already. This pytest Django tutorial runs on Python 3.10.6. But earlier versions also work perfectly. So we also assume you have Python running on your machine.

To start, create a project directory and make a new Python virtual environment in that folder. For this stage, you can use the virtualenvwrapper or Python’s built-in virtualenv package, depending on what works best for you. Ignore this step if you’re already working in a virtual machine or your project uses a containerized environment.

Next, install Django in your virtual environment.

We also used the markdown package for the website demo used in this pytest Django tutorial. So while it’s not a requirement, you might want to install it.

Create a requirements.txt file in your project root folder and list the packages as shown.

django  
django-markdown-deux

While django-markdown-deux is optional, it provides a markdown template for the pytest Django project. So I’ve added it since it’s a requirement for the Django project used in this pytest Django tutorial to work as expected.

Run the installation of the requirements using pip:

pip install -r requirements.txt

The installation runs as shown below.

_Let’s take a look which are the most wanted automated testing tools that have climbed the top of the ladder so far? _

Why use Django for large-scale websites?

The 2022 Stack Overflow Developer Survey shows that Python is one of the easiest programming languages. Since Django is a Python web framework, it allows you to develop a complex website by leveraging Python’s simplicity.

Some alternatives to Django include Flask, Pyramid, web2.py, CherryPy, Tornado, and FastAPI, among others. But Django’s structure smoothens the development pipeline, helping the development team to achieve a viable product on time.

Besides testing support, here are some reasons Django is suitable for developing large-scale websites:

Scalability

Django offers a robust and horizontally scalable architecture that allows you to add more layers to your website. Its URL pattern gives it rigidity for accommodating multiple requests at a time.

Top-notch security features

Django offers built-in security against cross-site scripting (XSS), clickjacking using the X-Frame-Option middleware, cross-site request forgery (CSRF), and SQL injection using query sets.

Built-in admin interface

Building an admin interface consumes development time. Django eliminates this, as it comes with a built-in, well-styled admin engine that’s easy to use for content creators and less programming-savvy individuals.

Object-relational mapping (ORM) support

Django’s ORM support allows it to link several models seamlessly in relational databases.

Seamless database setup

Using Django’s settings.py file

Easy SMTP integration

You can configure an SMTP protocol easily inside the settings.py. It also supports third-party, real-time SMTP monitoring tools like Sentry.

These features reduce development time, making Django a suitable Python framework for developing complex websites.

Testing a Django application with pytest

The next step is to configure your pytest Django project. This involves creating an initiation file that points your tests to your Django project settings file. But let’s install more dependencies before moving ahead.

Installation of Test Dependencies

Since this pytest Django tutorial demonstrates how to use Selenium and pytest for UI automation testing with Python in Django, we’ll install pytest, pytest-django, and Selenium.

To install these test packages, append the list of dependencies in your requirements.txt file as shown.

django
django-markdown-deux
pytest
pytest-django
selenium

Now, run the installation again.

pip install -r requirements.txt

The installation runs as shown. Note how it skips the dependencies we installed previously.

_With LambdaTest achieve faster, reliable, and scalable testing in a secure and efficient manner. Join thousands of users who trust our automation testing platform for their testing needs. _

What is pytest-django?

The pytest-django module is a pytest plugin that facilitates Django testing with pytest. It also lets you configure your pytest Django project to work inside the pytest.ini file.

Generally, pytest-django is the plugin that allows pytest to identify your Django project. Additionally, it lets you use pyest’s marker helpers, fixtures, and other pytest plugins with Django without hassle.

Configuration of pytest.ini

Next, create a pytest.ini file in your project root. This is an initialization file that connects your Django project with pytest. You can configure your test behavior using this file, including default database usage.

Below is the simple configuration used in this pytest Django tutorial.

[pytest]

DJANGO_SETTINGS_MODULE = django_blog.settings
filterwarnings = ignore::DeprecationWarning
addopts = --reuse-db

DJANGO_SETTINGS_MODULE points our test to the pytest Django project settings file. This is a feature of the pytest-django plugin that allows pytest to inherit the configurations of your Django project.

We use filterwarnings to ignore deprecation warnings since we want to see a clean log of our test runs. We also like the test execution to be as fast as possible. So we declare –reuse-db in the addopts configuration to allow our test to re-use the previous database instead of creating a new one for each test instance.

Creation of Django Test Directory

A dedicated test folder will enable you to separate your test suite from your pytest Django project. Doing this can be handy when the test codebase is large.

Go to your Django project root directory and create a new test folder. You can create other folders within this directory to handle your test files.

Project Structure

Below is how the project structure looks in VS Code:

Let’s take a closer look at the tests folder to see what each directory and file does.

FolderName — Blog-app/blog/tests

Do you use a Mac and want to run the test in Internet Explorer? This article explores how to test Internet Explorer on Mac.

Test Directory Structure

The Django test directory structure typically includes a “tests” module within each Django app directory, where app-specific tests can be organized and stored. Additionally, the project directory may also contain a top-level “tests” directory for project-wide tests that don’t belong to a specific app.

sel_selectors directory:

The sel_selectors folder contains the module that handles all DOM selectors for Selenium (sel_selectors.py). This module holds the selector class used to perform web actions in the test runner file (test_runner/test_module.py).

setup folder:

The setup directory has the file containing general test requirements and driver configuration for the Django test (setup.py). The setup.py file provides the Settings class for accessing the grid, opening the browser instance, closing the browser, and quitting the test suite.

test_runner folder:

This folder contains the main Python file (test_module.py) that runs the test suite and feeds pytest with relevant test information.

Demo: Testing the Django application with pytest

Let’s briefly explain our Django test goal before we begin.

Our project is a simple blog with an admin backend where a superuser can publish posts. So our test goal is to create the superuser for each test instance, visit the login page and log into the admin panel. Then fill in the form fields.

Below is a screenshot of the login page for our locally hosted Django website.

Then finally, we publish a post by ticking the Published checkbox and clicking the Submit button.

The admin page of the locally hosted Django website looks like this:

We expect to visit the homepage after publishing a post. So we create an action for that action as well. See the homepage below.

This section of the pytest Django tutorial will demonstrate the test using the locally hosted pytest Django project. We will do the same when finally hosted — you’ll see this later in the section of this pytest Django tutorial.

Test Scenario:

Below are our test steps:

Log on to the login page.
Fill out the username and password fields with the superuser’s credentials.
Click the login button to enter the post editor engine.
Fill out the post fields.
Tick the Published checkbox.
Click Submit to publish the post and visit the homepage.

Set up your Grid Tunnel to allow local testing

To run the locally hosted Django website, you need a tunnel to establish a connection with a Selenium cloud grid, like LambdaTest. So the tunnel serves as a temporary server for each test instance.

LambdaTest is a digital experience testing platform that enables you to perform Python web automation across 3000+ real browsers and platform combinations. It supports different Python-based testing frameworks like pytest for Selenium Python testing.

Visit our support documentation to get started with Selenium Python testing.

To set up a tunnel on the LambdaTest cloud grid:

Download a compatible version of the tunnel from LambdaTest. Extract the file once downloaded.
Go to the build section of your dashboard.
Click Configure Tunnel at the right.
Copy the tunnel connection string.

Open your command line to the extracted tunnel file destination.
Paste the copied string in the command line and press enter to start your tunnel.
The tunnel runs as shown below.

When you refresh your builds dashboard, Tunnel active replaces Configure Tunnel at the top right.

Are you using Playwright for automation testing? Run your Playwright test scripts instantly on 50+ browser/OS combinations using the LambdaTest cloud.

Add a conftest.py file

As mentioned, the conftest.py file holds test fixtures, which are perfect for handling test data, states, and dependencies.

In this pytest Django tutorial, we handle the superuser creation function for our test using the pytest fixture. We place it inside conftest.py since we want to separate it from the bulk Django test suite.

To add the conftest.py file to your Django test suite, create a new file in your test folder and name it conftest.py.

Below is our superuser creation fixture.

from django.contrib.auth.models import User
import pytest
import os
from dotenv import load_dotenv
load_dotenv('.env')
from django.test import LiveServerTestCase

@pytest.fixture
def superAdmin() -> User:
    return User.objects.create_user(
         'admin',
         'omisolaidowu@gmail.com,',
       os.getenv('SUPER_ADMIN_PASSWORD'),
       is_superuser=True
       )

@pytest.mark.usefixtures("superAdmin")
class admin(LiveServerTestCase):
  @pytest.fixture(autouse=True)
  def super(self, superAdmin):
    self.createSuperAdmin = superAdmin
    return self.createSuperAdmin

The above code creates a superuser for logging into the Django app. This fixture runs only once. So we don’t need to bother about duplicate user keys.

Creating a superuser for our test is easy since Django has a built-in User model. We import the User model from Django to create a superuser in the superAdmin function, which returns a User instance. Using the @pytest.fixture decorator, pytest sees this function as a fixture.

We also import the LiverServerTestCase class from Django. This provides a live server for running the UI test. When inherited, we can mimic a live test using the liver_server_url attribute.

However, superAdmin is a base fixture. Django knows to create a superuser from the given parameters because we set is_superuser to True.

As we mentioned, you can’t call a fixture directly in a test without passing it to a handler (typically, another fixture).

While you can call a fixture inside another directly without issues, it’s different when dealing with a class, as we need to pass the @ pytest. mark. usefixtures decorator over it.

The @ pytest. mark. usefixtures decorator allows you to specify the fixture to use in a class method. In this case, the admin class can feed its methods with the superAdmin function fixture, as listed in the usefixture decorator.

Although the test runner class (test_module.py) might inherit LiverServerTestCase directly, the admin class inherits it instead since the test runner class will still inherit the admin class.

Thus, while the test runner class inherits the admin attributes, it also does so LiverServerTestCase and can use the liver_server_url attribute from that class to open the web URL.

The super method has to be a fixture since only a pytest fixture can call another one directly before it’s usable in a test class or function. This class method returns an admin attribute (self.createSuperAdmin) using the superAdmin Pytest fixture.

Hence, calling self.createSuperAdmin in our test runner class creates a superuser with the specified email address and username for every test execution.

Setting up the Django test

The test setup follows the typical setup and tear-down functions for expanding the browser window and closing it, respectively.

However, you need to grab your grid username and access key if you’re using a cloud grid, as you need to provide these inside your desired capabilities.

If you’re using the LambdaTest cloud grid, follow these steps to get your username and access key.

1.Log into your LambdaTest Dashboard and go to the **Builds **directory.

2.Click the Access Key at the top right.

3.Copy the Username and Access Key fields and paste them into your environment variable (.env) file as shown.

LT_USERNAME = "Paste your username" LT_ACCESS_KEY = "Paste your access key"

Now let’s go ahead with the Django UI automation test setup.

from selenium import webdriver
from dotenv import load_dotenv
import os
load_dotenv('.env')

LT_USERNAME = os.getenv("LT_USERNAME")
LT_ACCESS_KEY = os.getenv("LT_ACCESS_KEY")


desired_caps = {
        'LT:Options' : {
            "user" : LT_USERNAME,
            "accessKey" : LT_ACCESS_KEY,
            "build" : "Django Functional Testing",
            "name" : "Django Test",
            "platformName" : "Windows 10",
            "tunnel": True

        },
        "browserName" : "FireFox",
        "browserVersion" : "103.0",

    }

class Settings:

    def __init__(self) -> None:
        self.grid_url = "@hub.lambdatest.com/wd/hub">https://{}:{}@hub.lambdatest.com/wd/hub".format(
            LT_USERNAME, LT_ACCESS_KEY
            )
        self.desired_caps = desired_caps
        self.driver = webdriver.Remote(command_executor=self.grid_url, desired_capabilities= self.desired_caps)

    def setup(self):
        self.driver.implicitly_wait(10)
        self.driver.maximize_window()
    def tearDown(self):
        if (self.driver != None):
            print("Cleaning the test environment")
            self.driver.quit()

We start the setup by importing the Selenium WebDriver. Next is the extraction of our grid username and access key from the .env file using the os.getenv function.

Specifying these variables inside the desired capabilities, as shown below, allows us to access the cloud grid browser and platform instance. And since the test uses a tunnel, we also add a tunnel option to desired_caps and set it to True, so the Selenium cloud grid knows we’re testing from a local machine.

Note: Since setting tunnel to True is only applicable when testing a locally hosted website, remove or set it to False when switching to a live test.

The grid URL also requires the username and access key for full access to the cloud grid. We declare this as an attribute of the Settings class. We further use this to configure the Selenium web driver (passed as self.driver), as shown below.

Next up are the setup and tearDown functions. The setup delays the browser for 10 seconds for the DOM to load resources. It then maximizes the browser window for web access.

The tearDown function checks if the test has a running driver and quits it if the condition is True.

However, the tearDown function must execute after the test runs all required scenarios. Otherwise, calling tearDown before any test scenario will close the browser and quit the Django test before completion.

LambdaTest’s mobile emulator online platform allows you to seamlessly test your mobile applications, websites, and web apps on various mobile browsers and devices, without having to own or physically access them.

Create the Selenium Selector Class

Getting the selectors from the DOM is easy since the project is probably still on your local machine. Even if you’ve deployed to production, inspecting the DOM via the browser exposes the web elements.

Inspecting the web elements

The project is still locally hosted in this case. We need Selenium to interact with two templates; templates/engine.html *and *templates/login.html.

Let’s view the login template to assess its DOM structure.

The engine template inherits its elements from the Django forms attribute. This is because we only want to call the form in the HTML template. Let’s see the forms.py file used in this pytest Django project for clarity.

The submit element is missing from the above form. You can find that in the original engine template.

Below is the original engine template. Look closely, and you’ll see that the Submit button has an id and a class of submit **and **submit-button, respectively.

Alternatively, you can inspect the website to pick the Selenium locators for each DOM element involved in the test.

For instance, to get the class selectors for the login form, visit the login URL and open the DOM structure using the browser’s inspect tool. Here’s what you get:

Now let’s create the selector module for our Django UI test

from selenium.webdriver.common.by import By
from dataclasses import dataclass

class formLocator:
    username = "username-fill" #class
    password = "password-fill" #class
    loginSubmit = "Login" #name
    published = "id_published" #id
    title = "my-title" #class
    content = "content-field" #class
    description = "-content-description" #class
    blogSubmit = "submit" #IDs


locate = formLocator()

@dataclass
class Webactions():
    driver: object

    def getWeb(self, URL):
        self.driver.get(URL)

    def getTitle(self):
        return self.driver.title

    def current_url(self):
        return self.driver.current_url

    def fill_username(self, username):
        self.driver.find_element(By.CLASS_NAME, locate.username).send_keys(username)

    def fill_password(self, password):
        self.driver.find_element(By.CLASS_NAME, locate.password).send_keys(password)

    def submit_login(self):
        self.driver.find_element(By.NAME, locate.loginSubmit).click()

    def published_yes(self):
        self.driver.find_element(By.ID, locate.published).click()

    def enter_title(self, title):
        self.driver.find_element(By.CLASS_NAME, locate.title).send_keys(title)

    def write_content(self, content):
        self.driver.find_element(By.CLASS_NAME, locate.content).send_keys(content)

    def enter_description(self, description):
        self.driver.find_element(By.CLASS_NAME, locate.description).send_keys(description)

    def submit_post(self):
        self.driver.find_element(By.ID, locate.blogSubmit).click()

The formLocator class contains the DOM selectors for the target web page. Thus, each is an attribute of the formLocator class.

Looking closely, every other selector in the formLocator class besides the submit buttons, username, and password fields inherit its identifier from the Django form shown previously.

Below is an extract of the formLocator class.

We also create a Webactions class to act on these selectors. The dataclass decorator adds a driver initiator to the webActions object. We’ve previously imported dataclass from Python’s built-in dataclasses package.

Thus, webAction instantiates with the Selenium WebDriver, which comes from the setup module (you’ll see the usage in the test runner (test_module.py).

This is similar to using the init method like so:

def __init__(self, driver):
    self.driver = driver

The getWeb, getTitle, and current_url methods of Webactions class fetch the website’s URL, the current page title, and the current page URL, respectively. While you can achieve this directly using driver.get, this approach allows you to customize and abstract your test.

The other methods in the Webactions class interact with the DOM selectors using the Selenium **By **class (we’ve imported this previously). However, those requiring form filling take an argument each.

For instance, a method whose selector uses an ID identifier locates its element using By ID. Each class method accesses the selectors by calling them from the formLocator class instance (locate.selector_name). We instantiate this class in the code as shown.

Below are the web actions that interact with the DOM.

Create the Test Execution File

from setup.setup import Settings
from conftest import admin
from sel_locators.sel_locators import Webactions
from django.contrib.auth.models import User

setUp = Settings()

blog = Webactions(setUp.driver)

class TestUserLoginFormSuccess(admin):

   def test_should_post_blog(self):
      setUp.setup()

      self.createSuperAdmin

      assert User.objects.count() == 1, "There should be only one superuser"

      blog.getWeb(self.live_server_url+'/login')

      assert "Log" in blog.getTitle(), "Error, log not in title"

      blog.fill_username('omisolaidowu')
      blog.fill_password('idowupaul')
      blog.submit_login()

      blog.getWeb(str(blog.current_url()))

      assert "Management" in blog.getTitle(), "Management must be on the next page"

      blog.published_yes()
      blog.enter_title("My First Blog")
      blog.write_content("Some lorem will be dumped here")
      blog.enter_description("Some blog descriptions")
      blog.submit_post()

      blog.getWeb(str(blog.current_url()))
      assert "Blog" in blog.getTitle(), "Blog must be on the next page"
      setUp.tearDown()

We start the above test execution by importing the Settings class from the setup file, which we instantiate as setUp. The Webaction instance also uses the driver attribute from the setUp object to initiate a blog instance. Our test uses the User model from Django (imported from django.contrib.auth.models) to assert the number of superusers in the database. We also import the admin class from conftest.py.

As shown previously, the admin class contains the fixture handler, which also inherits the LiverServerTestCase *to pull a live server for local testing. So this allows the test runner class (*TestUserLoginFormSuccess) to inherit the admin and LiveServerTestCase classes.

TestUserLoginForm has only one method (test_should_post_blog) running the test steps. Pytest automatically looks for this test method in the test_module.py file to execute the Django test suite.

That method starts by calling setUp.setup to maximize the browser window and initiate the Selenium WebDriver.

While you may not need to create a superuser in all Django test cases, only the superuser can access the editing engine in this case. So pytest needs the superuser credentials to log into the editor engine.

But pytest runs an instance of the Django test. Thus, it can’t use the superuser credentials you create using the python manage.py createsuperuser command. We need to create a dedicated superuser for our test — so it can access the admin panel and create a blog post.

So for the superuser creation, we call the createSuperAdmin action. This comes from the super fixture of the admin class inherited by the test runner class (TestUserLoginFormSuccess).

Once the superuser is created, the test leverages Django’s built-in User model to check if the superuser count in the database is more than one using pytest’s assert.

Selenium runs through the test method in the test class to execute each test step. These steps come from the webAction class — instantiated as a blog. Hence, each test step comes from this instance as blog.test_step.

Now, let’s go through each test step in the test_should_post_blog method.

Step 1 — Log on to the login page using the live_server_url attribute from Django’s LiveServerTestCase (inherited from the admin class). We also use pytest assert to check if a value exists in the page title.

The live_server_url provides a default localhost port for testing in Django. When concatenated with another route in the app, it results in a complete web directory.

For instance, [live_server_url+”/login”] might result in [http://localhost:54776/login]. The port number may vary, though. Checking one of our builds on the cloud grid shows that Django’s live_server_url runs on port 62409 for that instance.

As mentioned, this might change in another build. You don’t need to bother about how Django handles it.

Step 2 — Fill in the username and password field with the superuser’s credentials. These credentials must match the ones used to create a superuser in this Django test. Otherwise, the test fails while trying to assert a value match on the following page.

The test runs the following steps to fill out the login form with the superuser’s username and password.

Step 3 — Click the Login button to enter the post editor engine.

Once logged in, we expect to access the admin page, where the user can publish posts. You need to get the current URL to achieve this. To check if the test successfully navigates that page, we also assert that a value exists in its title.

Step 4— Tick the Published checkbox.

Step 5 — Fill out the post and title fields.

Step 6 — Click Submit to publish the post and visit the homepage.

The final stage in the test is to check successful URL navigation by asserting that a value exists in the homepage title.

Finally, we close the browser instance and end the test using the tearDown method of the Settings class.

Execution of the locally hosted Django website

To run the test, open the command line to your pytest Django project’s root folder and run the following command.

pytest

The test runs successfully on the cloud grid as shown below.

In this Appium tutorial, learn about Appium and its benefits for mobile automation testing. Take a look at how Appium works and see how to perform Appium Automation testing of your mobile applications.

Testing hosted version of the Django application with pytest and Selenium

While we’ve tested our Django website locally, you only require a few tweaks to make it reusable on a live website. The live demo version of the project is available at https://django-app-selenium-pytest-test.vercel.app.

So you can access the login page at https://django-app-selenium-pytest-test.vercel.app/login.

Our previous test only assessed the login and post-publishing functionalities. While you don’t have permission to create a superuser for the live version, you can create one at https://django-app-selenium-pytest-test.vercel.app/register.

Then execute the test using the registered credentials.

To repeat the test on the live version, you can separate the test folder from the pytest Django project and run the test independently.

When extracted from the local Django project, the test folder looks like this:

While other files in the test directory remain the same, you’ll make some changes to test_runner/test_module.py and setup/setup.py.

Remove the tunnel option from desired_caps in the setup file. Otherwise, the grid sees your build as coming from the local machine and fails the test.

Below is how the new setup.py code looks.

from selenium import webdriver
from dotenv import load_dotenv
import os
load_dotenv('.env')

LT_USERNAME = os.getenv("LT_USERNAME")
LT_ACCESS_KEY = os.getenv("LT_ACCESS_KEY")

print(type(LT_ACCESS_KEY))
print(type(LT_USERNAME))


desired_caps = {
        'LT:Options' : {
            "user" : LT_USERNAME,
            "accessKey" : LT_ACCESS_KEY,
            "build" : "Django Functional Live Testing",
            "name" : "Django Live Test",
            "platformName" : "Windows 11",

        },
        "browserName" : "Chrome",
        "browserVersion" : "104.0",

    }


class Settings:

    def __init__(self) -> None:
        self.grid_url = "@hub.lambdatest.com/wd/hub">https://{}:{}@hub.lambdatest.com/wd/hub".format(
            LT_USERNAME, LT_ACCESS_KEY
            )
        self.desired_caps = desired_caps
        self.driver = webdriver.Remote(command_executor=self.grid_url, desired_capabilities= self.desired_caps)

    def setup(self):
        self.driver.implicitly_wait(10)
        self.driver.maximize_window()
    def tearDown(self):
        try:
            if (self.driver != None):
                print("Cleaning the test environment")
                self.driver.quit()
        except  AssertionError as e:
            print(e)
            self.driver.quit()

The desired_caps dictionary in this one doesn’t have a tunnel option.

You might not need a conftest.py file for the live test, as we only used that to create a superuser in our case. You also need to remove LiveServerTestCase and the admin inheritance from the test runner class (TestUserLoginFormSuccess) since the website is now live.

Thus, the new test_module.py file looks like this:

import sys
sys.path.append(sys.path[0] + "/..")
from setup.setup import Settings

from sel_locators.sel_locators import Webactions

setUp = Settings()


blog = Webactions(setUp.driver)

class TestUserLoginFormSuccess():

   def test_should_post_blog(self):
      setUp.setup()

      blog.getWeb('https://django-app-selenium-pytest-test.vercel.app/login')
      assert "Log" in blog.getTitle(), "Error, log not in title"

      blog.fill_username('registered username')
      blog.fill_password('registered password')
      blog.submit_login()

      blog.getWeb(str(blog.current_url()))

      assert "Management" in blog.getTitle(), "Management must be on the next page"

      blog.published_yes()
      blog.enter_title("My First Blog")
      blog.write_content("Some lorem will be dumped here")
      blog.enter_description("Some blog descriptions")
      blog.submit_post()

      blog.getWeb(str(blog.current_url()))
      assert "Blog" in blog.getTitle(), "Blog must be on the next page"
      setUp.tearDown()

Live Test Execution

To run the live test, open your command prompt to the tests folder and run the following command.

pytest

The test runs on the cloud grid, as shown below.

If you’re looking to become an expert in automation testing and boost your Python skills, enrolling in a Selenium Python 101 certification program is an excellent first step. By doing this, you’ll lay a strong foundation for using Selenium Python in testing, paving the way for a successful career in this field.

Rounding Up: Simplify pytest Django UI automation testing with Selenium

In this Selenium pytest tutorial, we looked into performing local testing of your website UI, which helps you assess its functionalities and discover bugs before deploying it to production.

However, UI automation testing can be challenging without the appropriate tools to execute it. For versatile web frameworks like Django, pytest does the job excellently, as it fuses perfectly with Selenium and offers many built-in tools out of the box. Additionally, you can focus on writing your test script while pytest gives detailed information about your test execution.

In addition to linking every test file without complexity, you’ve also seen the power of pytest in connecting your test suite to your Django project settings. Overall, automation UI testing of a locally hosted and live Django website on a Selenium cloud grid is easy with a few configurations.

A comprehensive User Acceptance Testing (UAT) tutorial that covers what User Acceptance Testing is, its importance, benefits, and how to perform it with real-time examples.

Frequently Asked Questions (FAQs)

1. Can I use pytest with Django?

Yes, you can use pytest with Django. In fact, pytest is a popular testing framework for Python, and many developers prefer using it over Django’s built-in testing framework.

To use pytest with Django, you’ll need to install the pytest-django package, which provides many useful fixtures and plugins for testing Django applications.

2. Does Django use pytest or unittest?

Django includes its testing framework called unittest (also known as django.test), which provides a set of tools and classes for writing and running tests. unittest is similar to Python’s built-in unittest module but with some added features specifically designed for testing Django applications.

That being said, Django does not use pytest by default, but it can be used as an alternative testing framework instead of unittest. Many developers prefer using pytest over unittest because it offers a more concise and flexible syntax, powerful fixtures and plugins, and better test discovery mechanisms.

How To Generate Pytest Code Coverage Report

Idowu Omisola — Mon, 13 Mar 2023 08:39:29 +0000

The software quality level depends on how much you test. But it’s not unusual to miss some code parts or testing requirements during testing. This might result in bug or defect leakages if left unchecked. Code coverage helps you audit your test suite to determine which parts of your application are missing under test.

Thus, you can be sure where your test covers. While using test coverage, you’ll get analytical insights about parts of your program that you’ve covered, those missed, and those you need to test. Code coverage is even easier with Python, considering Python’s simplicity.

In this Selenium Python tutorial on pytest code coverage report, learn how to use code coverage with Python’s coverage.py using the pytest framework.

So, let’s get started!

What is Code Coverage?

Code coverage is a simple statistic that measures the total lines of code that a test suite validates. It uses set metrics to calculate the total number of lines of code in your application source code that runs successfully in a test — typically expressed as a percentage.

Theoretically, you can calculate code coverage by dividing the total code lines that run under a test by the sum of the lines of code subjected to testing. Then multiply the result by 100 to get a percentage coverage.

We can wrap this up using the simple mathematical equation below.

Code coverage = (total code lines testedtotal code lines subjected to testing) 100

For instance, testing a class containing 100 code lines in your source code involves subjecting the entire 100 lines of code to testing. If your test omits 40 lines of this class after testing, you can say your test suite has covered 60% of your code.

In that case, the number of actual code lines tested was 60, whereas the number of lines exposed to testing was 100. There might be bugs buried within the 40 omitted lines you don’t want to slip through to production. You want to improve your test and source code to increase coverage in that case.

Is 100 Percent Code Coverage Possible?

Here’s the thing: 100 percent code coverage isn’t enough reason to conclude that your application is free from bugs. For instance, you might still get 100% code coverage if you naively test functions, code lines, or components irrelevant to your app or its user story.

While it can be time and resource-intensive, it’s best to improve your code consistently rather than aim for crisp 100% code coverage. The essence of code coverage is to expose underlying bugs and get more insights about what your test suite needs to cover. Invariably, it helps you improve your test reach.

Our Gaming Platform Test Case Templates tutorial offers a step-by-step guide for effective test scenarios. Improve your game’s quality and performance today.

Code Coverage vs. Test Coverage

Many people, including testers and developers, use code and test coverage synonymously. But while these terms are closely related, there are still some differences.

Test Coverage

Test coverage is a qualitative black box validation of all the functionalities required to run an application smoothly. While analyzing this coverage type, you don’t need to understand the internal working mechanisms of the source code running the software under test.

For example, your application design typically lists specific features it must satisfy to be fully functional. As a QA engineer, you want to ensure that your test suite covers all the required functionalities before you verify the software’s quality.

Code Coverage

As explained, code coverage verifies the extent to which your test covers your source code. It’s a white-box approach that requires you to understand the underlying mechanisms of the source code driving the application under test.

Benefits of Code Coverage

Performing code coverage has many advantages.

It helps audit your test suite and check test completeness.
It prevents defect or bug leakage, as it helps you find and fix bugs in your source code easily.
It helps discover missing requirements easily.
It helps write better tests, increasing overall code quality.
It helps track and assess underused or garbage functions that usually introduce bugs.
It provides deeper code and user story insights and unveils more test cases, extending your test reach.
It enhances final software quality.

Types of Code Coverage

Code coverage can use a few different methods. We’ll discuss each below.

Branch Coverage

Branch coverage validates whether a test covers the code execution path. It’s part of code coverage that checks whether each branch in your code, including loops and conditions, runs at least once during testing.

Branch coverage is inclusive, as it seeks to leave no execution path unchecked. For instance, if you write a code that executes an action only if A > B, subjecting it to branch coverage first validates the condition (A > B). It then covers every statement (action) under that condition as well.

However, your test doesn’t cover the code if the condition (A > B) is false. To capture the branch, you might need to run a test where the boolean condition returns both true and false. And that’s why you need a solid working knowledge of the source code or application during unit testing.

Check out these top 50+ essential Mobile Development test cases to ensure your data’s integrity, accuracy, and consistency. Download our comprehensive template now

Statement Coverage

Statement coverage is more niche. Unlike branch coverage, it only validates the statements or actions within a code path. It doesn’t consider the parent code that prompts the execution of the action.

It means if a test doesn’t cover the branch that determines an action execution (if branch coverage is zero), statement coverage for that branch is also zero.

For example, if A > B is false, the branch statement (action) may not run under test. It’s safe to say statement coverage is partly dependent on branch coverage.

But sometimes, a test might fail to cover the statements (actions) under a branch if it contains a bug somewhere.

Decision Coverage

Decision coverage is a subset of branch coverage that verifies if a test covers all the conditions in the source code. Unlike branch coverage, which validates all code paths, including loops, decision coverage only checks the boolean conditions that run during testing.

Due to its design, decision coverage might omit false conditions, reducing the code coverage report.

Loop Coverage

Like decision coverage, loop coverage also falls under branch coverage. It validates the number (in percentage) of loops that run at least once under a test suite.

Function Coverage

Function coverage is the part of code coverage that evaluates the percentage of code functions that run during testing.

Why pytest for Code Coverage Report?

Pytest has plugins and supported modules for evaluating code coverage. Here are some reasons you want to use pytest for code coverage report generation:

It provides a straightforward approach for calculating coverage with a few lines of code.
It features a couple of code coverage tools.
It gives comprehensive statistics of your code coverage score.
It features plugins that can help you prettify pytest code coverage reports.
It features a command-line utility for executing code coverage.
It supports distributed and localized testing.

Now that I have covered the basics of the pytest code coverage report, let me walk you through some of the tools used for the pytest code coverage report.

CMS testing is required to ensure a content management system’s functionality, performance, security, and usability remain smooth.

Tools for Generating pytest Code Coverage Report

Here are some of the most-used pytest code coverage tools.

coverage.py

The coverage.py library is one of the most-used pytest code coverage reporting tools. It’s a simple Python tool for producing comprehensive pytest code coverage reports in table format. You can use it as a command-line utility or plug it into your test script as an API to generate coverage analysis.

The API option is recommended in case you need to prevent repeating a bunch of terminal commands each time you want to run the coverage analysis.

While its command line utility might require a few patches to prevent reports from getting muffed, the API option provides clean, pre-styled HTML reports that you can view via a web browser.

Below is the terminal line for executing code coverage with pytest using coverag.py.

coverage run -m pytest

The above command runs all pytest test suites with names starting with “test.”

All you need to do to generate reports while using its API is to specify a destination folder in your test code. It then overwrites the folder’s HTML report in subsequent tests.

You’ll see its API usage as you read further through the code coverage demonstration section.

pytest-cov

pytest-cov is a code coverage plugin and command line utility for pytest. It also provides extended support for coverage.py.

Like coverage.py, you can use it to generate XML or HTML reports and view a pretty code coverage analysis via the browser. Although using pytest-cov involves running a simple command via the terminal, the terminal command becomes longer and more complex as you add more coverage options.

For instance, generating a command-line-only report is as simple as running the following command:

pytest --cov

The result of the pytest –cov command is below:

But generating an HTML report requires additional command:

pytest --cov --cov-report=html:coverage_re

Where coverage_re is the coverage report directory.

Below is the report when viewed via the browser.

Here is a list of widely-used command line options with –cov:

–COV OPTIONS	null
-cov=PATH	Measure coverage for a filesystem path. (multi-allowed)
–cov-report=type	To specify the type of report to generate. Type can be HTML, XML, annotate, term, term-missing, or lcov. term, term- missing may be followed by “:skip-covered”. annotate, html, xml, and lcov may be followed by “:DEST” where DEST specifies the output location.
–cov-config=path	Config file for coverage. Default: .coveragerc
–no-cov-on-fail	Do not report coverage if the test fails. Default: False
–no-cov	Disable coverage report completely (useful for debuggers). Default: False
–cov-reset	Reset cov sources accumulated in options so far. Mostly useful for scripts and configuration files.
–cov-fail-under=MIN	Fail if the total coverage is less than MIN.
–cov-append	Do not delete coverage but append to current. Default: False
–cov-branch	Enable branch coverage.
–cov-context	Choose the method for setting the dynamic context.

Code Coverage Demonstration using coverage.py

The code coverage demonstration for this blog includes a test for the following:

A plain name tweaker class example to show why you may not achieve 100% code coverage and how you can use its result to extend your test reach.
Registration steps code coverage demonstration using the LambdaTest eCommerce Playground, executed on the cloud grid.

We’ll use Python’s coverage module, coverage.py, to demonstrate the code coverage for all the tests in this tutorial on the pytest code coverage report. So you need to install the coverage.py module since it’s third-party. You’ll also need to install the Selenium WebDriver (to access web elements) and python-dotenv (to mask your secret keys).

Create a requirements.txt file in your project root directory and insert the following packages:

coverage
selenium
python-dotenv
pytest

Next, install the packages using pip:

pip install -r requirements.txt

The command installs the required packages as shown:

As mentioned, coverage.py lets you generate and write coverage reports inside an HTML file and view it in the browser. You’ll see how to do this later.

Below is a screenshot of the project structure inside VS Code.

The locators folder contains the web locator for the LambdaTest playground test. However, the plain_test folder contains the test class for the example name tweaking scenario.

The run_coverage folder holds the test runners for the entire test suite. It also contains a dedicated folder for storing the auto-generated coverage reports.

The setup directory is the LamdaTest grid setup for the registration steps test case. And finally, the test scenario directory contains the file with the class that executes the web actions in locators.py.

Streamline your mobile app testing process with our tutorial on Xamarin Test Case Templates. Learn how to create comprehensive test cases efficiently.

How Code Coverage helps you extend your test reach: Name Tweaker Class Test Example

We’ll start by considering an example test for the name tweaking class to demonstrate why you may not achieve 100% code coverage. And you’ll also see how to extend your code coverage.

The name tweaking class contains two methods. One is for concatenating a new and an old name, while the other is for changing an existing name.

For this example:

class test_should_tweak_name:
    def __init__(self, name) -> None:
        self.name = name

    def test_should_addNames(self, name):
        if self.name == "LambdaTest":
            new_name = self.name+" "+name
            assert new_name == "LambdaTest Grid", "new_name should be LambdaTest Grid"
            return new_name
        else:
            return self.name

    def test_should_changeName(self, name):
        self.name = name
        assert self.name == "LambdaTest Cloud Grid", "new_name should be LambdaTest Cloud Grid"
        return name

To execute the test and get code coverage less than 100%, we’ll start by omitting a test case for the else statement in the first method and also ignore the second method entirely (test_should_changeName).

# Import the Pytest coverage plugin:
import coverage

# Start code coverage before importing other modules:
cov = coverage.Coverage()
cov.start()

# Main code to be covered----------:

import sys
sys.path.append(sys.path[0] + "/..")

from plain_tests.plain_tests import test_should_tweak_name

tweak_names = test_should_tweak_name("LambdaTest")
print(tweak_names.test_should_addNames("Grid"))

cov.stop()
cov.save()
cov.html_report(directory='coverage_reports')

Run the test by running the following command:

run_coverage/name_tweak_coverage.py

The coverage generates a report folder like so:

Go into the coverage_reports folder and run index.html via your browser. The test yields 69% coverage (as shown below) since it omits the two named instances.

Let’s extend the code coverage:

Although we’ve deliberately ignored the second method in that class, it was easy to forget to include a case for the else statement in the test. That’s because we only focused on validating the true condition. Including a test case that assumes negativity (where the condition returns false) extends the code coverage.

So what if we add a test case for the second method and another one that assumes that the supplied name in the first method isn’t LambdaTest?

The code coverage yields 100% since we’re considering all possible scenarios for the class under test.

So a more inclusive test looks like this:

# Import the Pytest coverage plugin:
import coverage

# Start code coverage before importing other modules:
cov = coverage.Coverage()
cov.start()

# Main code to be covered----------:

import sys
sys.path.append(sys.path[0] + "/..")

from plain_tests.plain_tests import test_should_tweak_name


tweak_names = test_should_tweak_name("LambdaTest")

will_not_tweak_names = test_should_tweak_name("Not LambdaTest")

print(tweak_names.test_should_addNames("Grid"))

print(tweak_names.test_should_changeName("LambdaTest Cloud Grid"))

print(will_not_tweak_names.test_should_addNames("Grid"))


# Stop code coverage and save the output in a reports directory---------:
cov.stop()
cov.save()
cov.html_report(directory='coverage_reports')

Adding the will_not_tweak_names variable covers the else condition in the test. Additionally, calling test_should_changeName from the class instance captures the second method in that class.

Extending the coverage this way generates 100% code coverage, as seen below.

How to Implement Code Coverage on the Cloud Grid?

We’ll build on the previous code structure for this test demo. Here, we’ll write test cases for the registration web actions on the LambdaTest eCommerce Playground. Then we’ll run the test on the LambdaTest cloud grid based on these actions without supplying some parameters; this might involve failure to fill in some form fields or submitting an invalid email address.

LambdaTest is a cloud-based continuous quality platform that enables you to conduct Python automation testing on a dependable and scalable online Selenium Grid infrastructure, spanning over 3000 real web browsers and operating systems. Additionally, it offers parallel test execution that can significantly reduce your build times while performing Python web automation.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated browser testing, Selenium testing, Cypress E2E testing, CI/CD, and more.

Discover the top 60 essential Healthcare Domain Testing Test Cases along with its importance, types and usage for better understanding.

We’ll compute the code coverage under the following test scenarios:

Submit the registration form with an invalid email address and missing fields.
Submit the form with all fields filled appropriately (successful registration).

We’ll also see how adding the missing parameters can extend the code coverage.

Setting up the test environment

from selenium import webdriver

from dotenv import load_dotenv
import os
load_dotenv('.env')

LT_GRID_USERNAME = os.getenv("LT_GRID_USERNAME")
LT_ACCESS_KEY = os.getenv("LT_ACCESS_KEY")

desired_caps = {
        'LT:Options' : {
            "user" : os.getenv("LT_GRID_USERNAME"),
            "accessKey" : os.getenv("LT_ACCESS_KEY"),
            "build" : "Test Coverage Idowu",
            "name" : "Firefox coverage demo2",
            "platformName" : os.getenv("TEST_OS")
        },
        "browserName" : "FireFox",
        "browserVersion" : "103.0",
    }
gridURL = "@hub.lambdatest.com/wd/hub">https://{}:{}@hub.lambdatest.com/wd/hub".format(LT_GRID_USERNAME, LT_ACCESS_KEY)

class testSettings:

    def __init__(self) -> None:
        self.driver = webdriver.Remote(command_executor=gridURL, desired_capabilities= desired_caps)

    def testSetup(self):
        self.driver.implicitly_wait(10)
        self.driver.maximize_window()
    def tearDown(self):
        if (self.driver != None):
            print("Cleaning the test environment")
            self.driver.quit()

Code Walkthrough

First, import the Selenium WebDriver to configure the test driver. Get your grid username and access key (passed as LT_GRID_USERNAME and LT_GRID_ACCESS_KEY, respectively) from the cloud grid.

The desired_caps is a dictionary of the desired capabilities for the test suite. It details your username, access key, browser name, version, build name, and platform type that runs your driver.

Next is the grid URL. We access this using the access key and username declared earlier. We then pass this URL and the desired capability into the driver attribute inside the init function.

Write a testSetup method that initiates the test suite. It works by using the implicitly_wait function to pause for the DOM to load elements. It then uses the maximize_window method to expand the chosen browser frame.

However, the tearDown method helps stop the test instance and closes the browser using the quit method.

To get your LambdaTest username and access key, go to the LambdaTest Builds Section of your dashboard and click Access Key at the top right to display this information.

from selenium.webdriver.common.by import Byfrom

from selenium.webdriver.common.by import By
from selenium.common.exceptions import NoSuchElementException

class element_locator:
    first_name = "//input[@id='input-firstname']"
    last_name = "//input[@id='input-lastname']"
    email = "//input[@id='input-email']"
    telephone = "//input[@id='input-telephone']"
    password = "//input[@id='input-password']"
    confirm_password = "//input[@id='input-confirm']"
    subscribe_no = "//label[@for='input-newsletter-no']"
    agree_terms = "//label[@for='input-agree']"
    submit = "//input[@value='Continue']"
    error_message = "//div[@class='text-danger']"

locator = element_locator()

class registerUser:
    def __init__(self, driver) -> None:
        self.driver=driver
    def error_message(self):  
        try:
            return self.driver.find_element(By.XPATH, locator.error_message).is_displayed()
        except NoSuchElementException:
            print("All code in registration test covered")

    def test_getWeb(self, URL):
        self.driver.get(URL)

    def test_getTitle(self):
        return self.driver.title
    def test_fillFirstName(self, data):
        self.driver.find_element(By.XPATH, locator.first_name).send_keys(data)
    def test_fillLastName(self, data):
        self.driver.find_element(By.XPATH, locator.last_name).send_keys(data)
    def test_fillEmail(self, data):
        self.driver.find_element(By.XPATH, locator.email).send_keys(data)
    def test_fillPhone(self, data):
        self.driver.find_element(By.XPATH, locator.telephone).send_keys(data)
    def test_fillPassword(self, data):
        self.driver.find_element(By.XPATH, locator.password).send_keys(data)
    def test_fillConfirmPassword(self, data):
        self.driver.find_element(By.XPATH, locator.confirm_password).send_keys(data)
    def test_subscribeNo(self):
        self.driver.find_element(By.XPATH, locator.subscribe_no).click()
    def test_agreeToTerms(self):
        self.driver.find_element(By.XPATH, locator.agree_terms).click()
    def test_submit(self):
        self.driver.find_element(By.XPATH, locator.submit).click()

Start by importing Selenium By object into the file to declare the locator pattern for the DOM. We’ll use the NoSuchElementException to check for an error message in the DOM (in case of invalid inputs). To learn more about it, go through this tutorial on handling errors and exceptions in Selenium Python.

Next, declare a class to hold the web elements. Then create another class to handle the web actions for the registration form.

The element_selector class contains the web element locations. Each uses the XPath locator.

The registerUser class accepts the driver attribute to initiate web actions. You’ll get the driver attribute from the setup class while instantiating the registerUser class.

The error_message method inside the registerUser class does two things. First, it checks for invalid field error messages in the DOM when the test tries to submit the registration form with unacceptable inputs. The check runs every time inside a try block. So the test covers it regardless.

Secondly, it runs the code in the try block if it finds an input error message element in the DOM. This prevents the except block from running, flagging it as non-covered code.

Otherwise, Selenium raises a NoSuchElementException. This forces the test to log the print in the except block and mark it as covered code. This feels like a reverse strategy. But it helps code coverage capture more scenarios.

So besides capturing omitted fields (web action methods not included in the test execution), it ensures that the test accounts for an invalid email address or empty string input.

Thus, if the error message is displayed in the DOM, the method returns the error message element. Otherwise, Selenium raises a NoSuchElementException, forcing the test to log the printed message, as shown below.

The rest of the class methods are web action declarations for the locators in the element_locator class. Excluding the fields that require a click action, the other class methods accept a data parameter, a string that goes into the input fields.

Now let’s run each test scenario to see its computed code coverage.

But first, create a test runner file for the code coverage scenarios. You’ll execute this file to run the test and calculate the code coverage.

# Import the Pytest coverage plugin:
import coverage

# Start code coverage before importing other modules:
cov = coverage.Coverage()
cov.start()

# Main code to be covered----------:

import sys
sys.path.append(sys.path[0] + "/..")
from testscenario.scenarioRun import test_registration

registration = test_registration()
registration.it_should_register_user()

# Stop code coverage and save the output in a reports directory---------:
cov.stop()
cov.save()
cov.html_report(directory='coverage_reports')

The above code starts by importing the coverage module. Next, declare an instance of the Coverage class and call the start method at the top of the code. Once code coverage begins, import the test_registration class from scenarioRun.py. Instantiate the class as registration.

The class method, it_should_register_user is a test method that executes the test case (you’ll see this class in the next section). Use cov.stop() to close the code coverage process. Then use cov.save() to capture the coverage report.

The cov.html_report method writes the coverage result into an HTML file inside the declared directory (coverage_reports).

And running this file executes the test and coverage report.

Now let’s tweak the web action methods inside scenarioRun.py to see the difference in code coverage for each scenario.

Scenario 1: Submit the registration form with an invalid email address and some missing fields.

import sys
sys.path.append(sys.path[0] + "/..")

from locators.locator import registerUser
from setup.setup import testSettings
import unittest
from dotenv import load_dotenv
import os

load_dotenv('.env')

setup = testSettings()

test_register = registerUser(setup.driver)

E_Commerce_palygroud_URL = "https:"+os.getenv("E_Commerce_palygroud_URL")

class test_registration(unittest.TestCase):

    def it_should_register_user(self):
        setup.testSetup()
        test_register.test_getWeb(E_Commerce_palygroud_URL)
        title = test_register.test_getTitle()

        self.assertIn("Register", title, "Register is not in title")

        test_register.test_fillEmail("testrs@gmail")

        test_register.test_fillPhone("090776632")
        test_register.test_fillPassword("12345678")
        test_register.test_fillConfirmPassword("12345678")

        test_register.test_submit()

        test_register.error_message()

        setup.tearDown()

Pay attention to the imported built-in and third-party modules. We start by importing the registerUser and testSettings classes we wrote earlier. The testSettings class contains the testSetup() and tearDown() methods for setting up and closing the test respectively. We instantiate this class as a setup.

As seen below, the registerUser class instantiates as test_register using the setup’s driver attribute. We also need the unittest’s assert function. So we import that at the top level as well. The dotenv package lets you get the test website’s URL from the environment variable.

The test.testSetup method initiates the test case (it_should_registerUser method) and prepares the test environment. Next, we launch the website using the test_getWeb method. This accepts the website URL declared earlier. The inherited property from the unittest test, assertIn, checks whether the declared string is in the title. Use the setup.tearDown to close the browser and clean the test environment.

As earlier stated, the rest of the test case omits some methods from the registerUser class to see its effect on code coverage.

Scenario 1 code coverage execution:

To execute the test and code coverage, cd into the test_run_coverage folder and run the run_coverage.py file using pytest:

pytest

Once the code runs successfully, open the coverage_reports folder and open the index.html file via a browser. The code coverage reads 94%, as shown below.

Although the other test files read 100%, locator.py has 89% of its code covered, reducing the overall score to 94%. This is because we omitted some web actions and filled in an invalid email address while running the test.

Opening locator.py gives more insights into the missing steps (highlighted in red), as shown below.

Although you might expect the coverage to flag the test_fillEmail method, it doesn’t because the test provided an email address; it was only invalid. The except block is the invalid parameter indicator. And it only runs if the input error message element isn’t in the DOM.

As seen, the test flags the except block this time since the input error message appears in the DOM due to invalid entries.

The test suite runs on the cloud grid with some red flags in the test video, as shown below.

Scenario 2: Submit the form with all fields filled appropriately (successful registration).

import sys
sys.path.append(sys.path[0] + "/..")

from locators.locator import registerUser
from setup.setup import testSettings
import unittest
from dotenv import load_dotenv
import os

load_dotenv('.env')

setup = testSettings()

test_register = registerUser(setup.driver)

E_Commerce_palygroud_URL = "https:"+os.getenv("E_Commerce_palygroud_URL")

class test_registration(unittest.TestCase):


    def it_should_register_user(self):

        setup.testSetup()
        test_register.test_getWeb(E_Commerce_palygroud_URL)
        title = test_register.test_getTitle()

        self.assertIn("Register", title, "Register is not in title")

        test_register.test_fillFirstName("Idowu")
        test_register.test_fillLastName("Omisola")

        test_register.test_fillEmail("testrs@gmail.com")

        test_register.test_fillPhone("090776632")
        test_register.test_fillPassword("12345678")
        test_register.test_fillConfirmPassword("12345678")
        test_register.test_subscribeNo()
        test_register.test_agreeToTerms()
        test_register.test_submit()

        test_register.error_message()

        setup.tearDown()

Scenario 2 has a similar code structure and naming convention to scenario 1. However, we’ve expanded the test reach to cover all test steps in scenario 2. Import the needed modules as in the previous scenario. Then instantiate the testSettings and registerUser classes as setup and test_register, respectively.

To get an inclusive test suit, ensure that you execute all the test steps from the registerUser class, as shown below. We expect this to generate 100% code coverage.

Scenario 2 code coverage execution:

Go into the run_coverage folder and run the pytest command to execute the test_run_coverage.py file:

pytest

Open the index.html file inside the coverage reports via a browser to see your pytest code coverage report. It’s now 100%, as shown below. This means the test doesn’t omit any web action.

Below is the test suite execution on the cloud grid.

If you’re aiming to develop expertise in automation testing and enhance your skills in Python, pursuing a Selenium Python 101 certification can be a great starting point. Doing so can establish a solid base in utilizing Selenium Python for testing, setting you on the path to a thriving career in this domain.

Here you will get to know about what is insurance domain and how it works. further, we have included all major and miscellaneous test cases, which every tester should verify during insurance domain testing.

Conclusion

Manually auditing your test suite can be an uphill battle, especially if your application code base is large. While performing Selenium Python testing, leveraging a dedicated code coverage tool boosts your productivity, as it helps you flag untested code parts to detect potential bugs easily. Although you’ll still need human inputs to decide your test requirements and coverage, performing a code coverage analysis gives you clear direction.

As you’ve seen, Python even brings further simplicity to code coverage with detailed human-friendly reports.

Frequently Asked Questions (FAQs)

1. How do I create a Pytest code coverage report?

Pytest is a popular testing framework for Python, and it includes a built-in plugin for generating coverage reports called pytest-cov. You can customize the coverage report by passing additional options to pytest-cov, such as ignoring certain files or setting a minimum coverage threshold.

2. What is code coverage in Python Pytest?

Code coverage measures how much of your code is executed during automated tests. In the context of Python and pytest, code coverage refers to the percentage of code lines that are executed during tests.

Pytest has a built-in coverage plugin, pytest-cov, that can measure code coverage during testing. When you run your tests with pytest-cov, it tracks which lines of code are executed during the tests and generates a report showing the coverage percentage for each file.

Playwright Python Tutorial: Getting Started With Python End To End Testing

Idowu Omisola — Wed, 21 Dec 2022 22:33:31 +0000

It’s essential to test all components of your website to see if they work as expected. Playwright’s end to end testing capability helps you achieve this easily. However, if you’re comfortable using Python, you can pair it with the Playwright testing framework to run Python end to end testing on your website.

The Playwright testing framework is more straightforward and lightweight than most alternatives, including Cypress and TestCafe, among many others. To give it a boost, it also offers API testing. Hence, it’s an excellent choice for end to end testing.

In this Playwright Python tutorial, you’ll learn how to combine Python’s simplicity with Playwright’s utility for end to end testing. But let’s start by understanding end to end testing and why you want to use Playwright to execute your test.

What is End to End Testing?

End to end testing is a method that validates the entire usage flow of an application to ensure that every part of it works as expected. It involves paying attention to every detail and extending the test coverage to discover and fix bugs. Its ultimate goal is to help you build a bug-free site.

Hence, it’s an adopted methodology for testing complex websites. Generally, it involves picking up your website’s user story and simulating your users’ behavior in different integration environments.

During end to end testing, you want to consider operating system and browser variability, among many other factors determining an app’s viability. Therefore, it involves conducting a critically inclusive test — from the back (API testing) to the front end.

With that in mind, automated end to end testing reduces testing costs, improves application integrity, and helps your product ship faster.

What is Playwright?

Playwright, released by Microsoft in 2020, is an open-source, cross-platform automation testing framework. It supports many browsers, including Chromium, Firefox, and Microsoft Edge, as well as WebKit-based applications. So it provides a handy toolkit for testing web and mobile applications.

It also works with most modern programming languages. As of writing, it supports JavaScript, Python, TypeScript, .NET, and Java. This Playwright Python tutorial will look into how to perform end to end tests with Playwright using Python.

Why use Playwright for Python end to end testing?

The Playwright framework has many event igniters that let you interact with different client-side features of your website like a real user. And it plays well with both synchronous and asynchronous requests. Thus, you can choose to run your test sequentially or leverage the power of Python’s asyncio **package to run test steps concurrently using **async/await. The latter is handy for interacting with websites that run tasks asynchronously.

Its API testing capability also helps you validate requests and responses on your app’s endpoints.

Depending on the specified test browser, the Playwright also isolates each test per browser. Thus, each test case in Playwright is a browser context, which defines a browser instance generated rapidly to reduce overhead.

Considering Playwright’s versatile utility and Python’s simplicity and acceptance, combining both to write your test script eases automation testing. Besides, the 2021 Stackoverflow Developer Survey puts Python in third place among the most used programming languages.

The Playwright framework is popular, with over 2,000 forks and over 41,800 stars on GitHub. And what’s more? It also has fair enough mentions on Stack Overflow with a good community. So you can always get help resolving bugs in your tests.

Unlike Selenium, where you might have to define custom timeout intervals to prevent false failure if elements fail to load, Playwright has an auto-wait feature that tentatively pauses for DOM elements to load before executing further steps in the test case. This wait time defaults to 30 seconds before it times out, but you can extend this using Playwright’s built-in wait_for_timeout() function. Hence, you’ll have a lower false failure probability with Playwright.

Playwright also provides an inspector tool, which you can use to generate selectors easily as you write your test. This helps reduce or even eliminate the need to inspect the browser manually.

Its code generator works in a play-and-record fashion. You can use it to spin up your app’s UI and auto-generate test scripts in any language as you interact with the DOM. Although this might be handy if you’re unfamiliar with coding, it’s less customizable. It doesn’t suit complex websites (e.g., e-commerce, banking, fintech, and more), as the code generated is often lengthy and complex.

These features, coupled with its intuitive selector and locator classes, make Playwright an excellent end to end testing framework.

Playwright GitHub trends as of writing this Playwright Python tutorial:

Stars: 41.8k
Used by: 14.1k
Forks: 2k
Watchers: 360
Contributors: 274
Releases: 79

Before we deep dive into this Playwright Python tutorial, let’s see how to install Playwright for Python end to end testing and set up the test project.

Run Automated Playwright Python Tests Online. Try LambdaTest Now!

Check this out: Data Driven Testing: A Comprehensive Guide With Examples and Best Practices

How to setup Playwright for Python end to end testing?

You have to install and set up your computer to start using Playwright Python for automation testing. However, this Playwright Python tutorial assumes that your machine runs on Python 3.

Step 1: Install Python’s latest version.

Go to the official Python website to download and install the latest version of Python on your machine.

The Windows OS doesn’t come with Python by default, so you’ll have to install it explicitly. However, ensure that you allow the installer to add Python to your system variable path during installation. Else you’ll have to do this manually later.

To install Python on Windows OS:

Open the installation file.
Click the Add Python to Path checkbox at the installation window’s bottom right. Then click Install Now.
The installation initializes and starts in the following menu.

While most Linux distributions may have Python pre-installed by default, you might still have to upgrade to a more recent version, as the system version might be obsolete to run Playwright. Playwright, however, works with Python version 3.7 or later.

To install Python on Linux from scratch:

  sudo apt-get install python 3

Step 2. Install Playwright and its WebKit.

You can install Playwright using pip:

   pip install playwright

If you’re on Linux or Mac, you can use **pip3 **instead, which works with Python 3 on these platforms:

pip3 install playwright

Either of the above commands run the Playwright installer:

And if you’re using **conda **to manage dependencies:

   conda install playwright

Depending on your choice of Python dependency installer, the above commands install the Playwright framework into your machine or Python virtual environment (if you use one).

And to install the Playwright WebKit:

  playwright install

The above command installs Playwright’s built-in WebKit. You’ll use this to bring up test scenarios for different web browsers.

Step 3. Create Project Folder.

The next step in this Playwright Python tutorial is to create a project folder for your automated testing. You can create one from the command line or your graphic user interface.

We’ll use Visual Studio Code on the Windows platform in this Playwright Python tutorial. But you can use any IDE that works best for you.

To create a folder on Windows and open it with VS Code:

Open any folder on your PC and right-click a blank space. Go to New > Folder.
Name your folder; this can be a descriptive name (for example playwright_test_folder).
Now, open VS Code to your project folder. Open VS Code and click Open Folder. Go to the folder you created earlier and select it to open VS Code to that directory.

Now that you’ve seen how to set up a development environment for testing your app in Python using Playwright — let’s dive into the coding aspect. But before that, remember we mentioned that Playwright has a code generator in this Playwright Python tutorial.

You’ll see how this code generator works in the following section of this tutorial on Playwright Python since it shows you how to select elements on your website when writing tests.

Run your Playwright test scripts instantly on 50+ browser and OS combinations. Try LambdaTest Now!

Check this out: Jest testing Tutorial: Complete Guide to Jest Testing

How does the Playwright Code Generator work?

As mentioned in the earlier section of this Playwright Python tutorial, the Playwright code generator makes it easy to scan the DOM without going to the inspection tab of your browser. Although it limits browser selection flexibility and is not as clean as writing custom tests, it’s also a nifty way for no-code lovers to auto-generate test scripts while interacting with the UI.

The code generator works in two ways. You can use it to pick out your website’s selectors. Or you can generate an entire test case script with its record and play functionality.

Open your terminal to your project root folder and use the following command to spin up a selector generator for your app. In my case, I’ll use the LambdaTest e-commerce playground, so remember to replace this with your website’s URL:

    playWright codegen https://ecommerce-playground.lambdatest.io/

The above command generates the appropriate selectors as you hover on the elements on a web page:

Look at the image above closely. You’ll see that the My account dropdown on that page generates a selector. This helps determine how the Playwright locator finds elements or features during testing.

To generate a test script into a Python file from your interaction with the target website, paste the following command in your terminal, replacing https://ecommerce-playground.lambdatest.io/ with your app’s URL:

    playwright codegen — target python -o example2.py https://ecommerce-playground.lambdatest.io/

The above command brings up a browser like the first one. But this time, it tells Playwright to write test code into the target file (example2.py) as you interact with the specified website. You don’t need to create the target file explicitly. The Playwright does this automatically.

Now open your text editor to your project folder. You should see the generated Python script (example2.py in my case).

Here’s the website and the code generated from interacting with it below:

If you place the generated Python script and the website side-by-side, as shown above, you’ll see the code changing dynamically in the Python script as you interact with your app.

Pros of the Playwright Code Generator:

It auto-generates code, which can be a good starting point if you need to extend the use case further.
Handy for picking test selectors in custom automated tests.
You can generate code for any Playwright-supported programming language.

Cons of the Playwright Code Generator:

Generated code is not scalable and maintainable.
It’s not suitable for testing complex websites.
There’s no way to execute parallel tests since it only generates one code file.
The generated code is hard to read and debug.
It doesn’t provide room for connecting to a cloud grid.
The codebase becomes messier as you generate more tests.
The test cases are repetitive.

Check this out: Appium Cloud For App Automation- Test your Native, Hybrid, and Web Apps on Appium mobile device cloud of 3000+ different real devices.

Playwright Locators and Selectors

As with most testing frameworks, locators and selectors are some of the core features of Playwright.

Like Selenium locators, you use Playwright selectors to specify the position of an element within the DOM. The locator is a class that points Playwright to the specified DOM elements so it can perform events on them.

The locator holds off an event and triggers auto-wait, which keeps retrying the test but fails after 30 seconds if it can’t find an element. The locator and selector in Playwright work hand-in-hand.

For example, the following locator performs a click event on the selected element:

    page.locator(‘input[name=”Search”]’).click()

The selector in the above example is ‘input[name=”search”]’, while the page.locator() function points to the selected element to perform JavaScript events on it (a click event in this case). However, the page, in this case, is a browser context instance.

Check this out: How To Debug Websites Using Developer Tools for safari

Implementing Python end to end testing with Playwright

Before you start testing, you may want to inspect the website elements to pick the selectors for your test. Place your cursor on a web element > right-click it and go to *Inspect *(for Chrome or any other web browser of your choice).

Tip: You can use the Playwright code generator to generate the selectors instead. Simply launch it using the playwright codegen Website_URL command. Hover over the elements and reuse the generated selectors in your test code.

As mentioned earlier, Codegen is extremely useful when it comes to generating selectors since selectors are an integral part of any automation test code.

We would run the tests using Playwright Python in series and parallel. And our test scenario will consider a practical user story to demonstrate our end to end test. Read through this Playwright Python tutorial to learn more about parallel testing.

We’ll run our test on the LambdaTest cloud grid. So you’ll need to grab your username and secret key from your LambdaTest Build Dashboard by clicking the Access Key tab at the top-right:

By using a cloud testing platform like LambdaTest, you can dramatically cut down the time taken to run your Playwright Python tests by using a browser farm of 50+ browsers and browser versions of Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and even Webkit.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around automated browser testing, Cypress E2E testing, Mobile App Testing, and more.

Check this out: How To Debug Websites Using dev tools in Safari

The tests are demonstrated using the LambdaTest e-commerce playground. The use cases for this Playwright Python tutorial are below:

Test Scenario — 1 (New User Registration)

The user launches the LambdaTest e-commerce playground registration page.
Fills out the registration form.
User submits the registration form.
Go to their dashboard for the first time.

Test Scenario — 2 (Login and Purchase Item)

The user logs in another time with the registered account.
Searches for a product.
The user selects the product searched for in step.
Adds the product to the cart.
The user checks out.
Perform logout.

Playwright Python Test Structure:

We will adopt the Page Object Model (POM) design pattern to structure the test project. So our code structure, in this case, separates concerns into different files in separate folders for modularization. This helps us scale our code later on and get rid of complexities.

Maintainability and scalability of the source code are some of the biggest plus points of the Page Object Model design pattern.

For instance, you might want to separate parallel test cases from single ones along the line.

Here’s the Playwright Python test structure:

  Project Directory
            |-----------elementSelectors
            |                 |----------------loginAndBuySelectors.py
            |                 |----------------registrationPageSelectors.py
            |
            |------------testCapabilities
            |                 |-----------------testCaps.py
            |
            |-------------testScenarios
            |                 |-----------------.env
            |                 |-----------------parallelLoginBuyRun.py
            |                 |-----------------parallelSignupRun.py
            |                 |-----------------singleLoginBuyRun.py
            |                 |-----------------singleSignupRun.py
            |
            |---------------testScripts
                              |-----------------parallelLoginBuyScript
                              |-----------------parallelSignup.py
                              |-----------------singleLoginBuyScript.py
                              |-----------------singleSignupScript.py

The elementSelectors folder contains the selectors for all the test scenarios. All the capabilities required to run all the test suites are inside the testCapabilities directory. This folder has only one file, which defines the capabilities shared by all test cases.

We also place all test actions (event handlers) inside the **testScripts **folder. Each file in this folder holds the class handling event methods. And finally, the **testScenarios **directory contains the test runners for each test case. To run any test, you only need to run each file here.

Therefore, we have to place the .env file in this testScenarios *folder since all imported modules will pick declared environment variables from it while running the test. Remember that the *.env file holds all secret parameters, including your cloud grid key and username.

Here’s the VS Code screenshot of the project directory used for this Playwright Python tutorial:

Now, we start by setting up the test capabilities for the entire test suite.

Test Capabilities Implementation:

*FileName *—testCapabilities / testCaps.py

   import json
    import os
    import urllib.parse
    import subprocess
    from dotenv import load_dotenv

    load_dotenv('.env')
    username = os.getenv("my_username")
    gridAcessKey = os.getenv("access_key")

    playwrightVersion = str(subprocess.getoutput('playwright --version')).strip().split(" ")[1]


    capabilities =[{
            'browserName': 'Chrome',  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
            'browserVersion': 'latest',
            'platform': 'Windows 10',
            'build': 'E2E for Chrome POM',
            'name': 'Playwright Test',
            'user': username,
            'accessKey': gridAcessKey,
            'console': True,
            'playwrightversion': playwrightVersion
        },
        {
            'browserName': 'MicrosoftEdge',  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
            'browserVersion': 'latest',
            'platform': 'Windows 10',
            'build': 'E2E for POM Egde',
            'name': 'Playwright Test Case 2',
            'user': username,
            'accessKey': gridAcessKey,
            'console': True,
            'playwrightversion': playwrightVersion
        }
        ]

    class testCapabilities:
        def __init__(self) -> None:
            self.lambdatestGridURL = 'wss://cdp.lambdatest.com/playwright?capabilities='

        def Chrome(self):
            self.stringifiedCaps = urllib.parse.quote(json.dumps(capabilities[0]))
            return self.lambdatestGridURL+self.stringifiedCaps
        def Edge(self):
            self.stringifiedCaps1 = urllib.parse.quote(json.dumps(capabilities[1]))
            return self.lambdatestGridURL+self.stringifiedCaps1

Check this out: Emulator vs Simulator vs Real Device Testing: Key Differences

Playwright Python Code Walkthrough:

The testCaps.py file contains the capabilities module required to run all our test cases, including single and parallel tests. So you don’t have to change it for subsequent test cases while running the Playwright Python test — unless you want to add more capabilities to the array, which involves scaling the methods.

You start by importing all the necessary packages to run this Playwright Python module.

    import json
        import os
        import urllib.parse
        import subprocess
        from dotenv import load_dotenv

Next, load your cloud grid access key and username from the environmental variables using the dotenv package, as you’ll provide them in the capabilities:

    load_dotenv('.env')
        username = os.getenv("my_username")
        gridAcessKey = os.getenv("access_key")

You’ll also provide the Playwright version as a string inside the test capability. In this case, we extract this value using the subprocess module. Then we clean it with Python’s built-in **strip **and **split **functions:

    playwrightVersion = str(subprocess.getoutput(‘playwright — version’)).strip().split(“ “)[1]

Each capability is a dictionary specifying settings for the test. There are two capabilities in the array — in this case (Chrome and Microsoft Edge). Therefore we can call them individually in separate methods using an array index. And that makes it easy to scale to perform cross browser testing using Playwright Python — even in parallel.

    capabilities =[{
                'browserName': 'Chrome',  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
                'browserVersion': 'latest',
                'platform': 'Windows 10',
                'build': 'E2E for Chrome POM',
                'name': 'Playwright Test',
                'user': username,
                'accessKey': gridAcessKey,
                'console': True,
                'playwrightversion': playwrightVersion
            },
            {
                'browserName': 'MicrosoftEdge',  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
                'browserVersion': 'latest',
                'platform': 'Windows 10',
                'build': 'E2E for POM Egde',
                'name': 'Playwright Test Case 2',
                'user': username,
                'accessKey': gridAcessKey,
                'console': True,
                'playwrightversion': playwrightVersion
            }
            ]

The **testCapabilities **class holds the Chrome and Microsoft Edge capability methods. First, you initialize this class with the cloud grid URL:

    class testCapabilities:
            def __init__(self) -&gt; None:
                self.lambdatestGridURL = 'wss://cdp.lambdatest.com/playwright?capabilities='

The LamdaTest grid URL for Playwright, as indicated above, is self.lambdatestGridURL.

You then extract the capability for each browser method (Chrome and Edge) using its index position. Then concatenate each with the grid URL inherited from the init function.

The **Chrome **method capability dictionary is at index zero (first item in the array):

    self.stringifiedCaps = urllib.parse.quote(json.dumps(capabilities[0]))
                return self.lambdatestGridURL+self.stringifiedCaps

The Edge() method gets the second dictionary in the array:

    self.stringifiedCaps1 = urllib.parse.quote(json.dumps(capabilities[1]))
                return self.lambdatestGridURL+self.stringifiedCaps1

Hence, this design helps you run your test singly or in parallel based on the different capabilities.

Implementation of the Registration Test Scenario:

*FileName *—elementSelectors/registrationPageSelectors.py

    webElements = {
        'webpage': "https://ecommerce-playground.lambdatest.io/index.php?route=account/register",
        'First_Name': 'input[placeholder="First Name"]',
        'Last_Name': 'input[placeholder="Last Name"]',
        'E-Mail': 'input[placeholder="E-Mail"]',
        'Telephone': 'input[placeholder="Telephone"]',
        'Password': 'input[placeholder="Password"]',
        'Confirm_Password': 'input[placeholder="Password Confirm"]',
        'Subscribe': 'label:has-text("No")',
        'Privacy_Policy': 'label:has-text("I have read and agree to the Privacy Policy")',
        'Submit': 'input[value="Continue"]',
        'Continue': "text=Continue"
    }


    class elementSelector:
        def __init__(self) -> None:
            self.webpage = webElements["webpage"]
            self.firstname = webElements["First_Name"]
            self.lastname = webElements["Last_Name"]
            self.email = webElements["E-Mail"]
            self.telephone = webElements["Telephone"]
            self.password = webElements["Password"]
            self.confirmpassword = webElements["Confirm_Password"]
            self.subscribe = webElements["Subscribe"]
            self.privacypolicy = webElements["Privacy_Policy"]
            self.submit = webElements["Submit"]
            self.todashboard = webElements["Continue"]

        def webPage(self):
            return self.webpage
        def firstName(self):
            return self.firstname
        def lastName(self):
            return self.lastname
        def eMail(self):
            return self.email
        def Telephone(self):
            return self.telephone
        def Password(self):
            return self.password
        def confirmPassword(self):
            return self.confirmpassword
        def Subscribe(self):
            return self.subscribe  
        def privacyPolicy(self):
            return self.privacypolicy
        def Submit(self):
            return self.submit
        def goToDashboard(self):
            return self.todashboard

*FileName *—testScripts / singleSignupScript.py

    from playwright.sync_api import sync_playwright
    import sys
    sys.path.append(sys.path[0] + "/..")


    from elementSelectors.registrationPageSelectors import elementSelector
    from testCapabilities.testCaps import testCapabilities

    select = elementSelector()

    capability = testCapabilities()

    def set_test_status(page, status, remark):
            page.evaluate("_ => {}",
            "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")


    class Register:
        def __init__(self, playwright) -> None:
            self.browser = playwright.chromium.connect(capability.Chrome())
            page = self.browser.new_page()
            self.page = page
        def launchWeb(self):
            self.page.goto(select.webPage())
            title = self.page.title()
            print(title)

        def fillFirstName(self, data):
            self.page.locator(select.firstName()).fill(data)

        def fillLastName(self, data):
            self.page.locator(select.lastName()).fill(data)

        def fillEmail(self, data):
            self.page.locator(select.eMail()).fill(data)

        def fillPhone(self, data):
            self.page.locator(select.Telephone()).fill(data)

        def fillPassword(self, data):
            self.page.locator(select.Password()).fill(data)

        def confirmPassword(self, data):
            self.page.locator(select.confirmPassword()).fill(data)

        def subscribe(self):
            self.page.locator(select.Subscribe()).click()

        def acceptPolicy(self):
            self.page.locator(select.privacyPolicy()).click()

        def submit(self):
            self.page.locator(select.Submit()).click()

        def continueToDashboard(self):
            self.page.locator(select.goToDashboard()).click()

        def getSuccessStatus(self):
            return set_test_status(self.page, "passed", "Success")

        def getFailedStatus(self):
            return set_test_status(self.page, "failed", "Test failed")

        def closeBrowser(self):
            self.browser.close()

*FileName *—testScenario / singleSignupRun.py

    import sys
    sys.path.append(sys.path[0] + "/..")

    from testScripts.singleSignupScript import Register
    from playwright.sync_api import sync_playwright


    with sync_playwright() as playwright:

        try:
            playwright = Register(playwright)
            playwright.launchWeb()
            playwright.fillFirstName("Idowu")
            playwright.fillLastName("Omisola")
            playwright.fillEmail("anEmailgmai@gmail.com")
            playwright.fillPhone("08122334433")
            playwright.fillPassword("mypassword")
            playwright.confirmPassword("mypassword")
            playwright.subscribe()
            playwright.acceptPolicy()
            playwright.submit()
            playwright.continueToDashboard()
            playwright.getSuccessStatus()
        except:
            playwright.getFailedStatus()

        playwright.closeBrowser()

Playwright Python Code Walkthrough:

FileName — elementSelectors / registrationPageSelectors.py:

We insert all the web element selectors, including the test site URL, into a dictionary inside the registrationPageSelectors.py file:

For instance, the Email field selector takes this format in the dictionary:

    ‘E-Mail’: ‘input[placeholder=”E-Mail Address”]’

The entire element selector dictionary looks like this:

    webElements = {
            'webpage': "https://ecommerce-playground.lambdatest.io/index.php?route=account/register",
            'First_Name': 'input[placeholder="First Name"]',
            'Last_Name': 'input[placeholder="Last Name"]',
            'E-Mail': 'input[placeholder="E-Mail"]',
            'Telephone': 'input[placeholder="Telephone"]',
            'Password': 'input[placeholder="Password"]',
            'Confirm_Password': 'input[placeholder="Password Confirm"]',
            'Subscribe': 'label:has-text("No")',
            'Privacy_Policy': 'label:has-text("I have read and agree to the Privacy Policy")',
            'Submit': 'input[value="Continue"]',
            'Continue': "text=Continue"
        }

Next is to turn these into the attributes that initiate the elementSelector class by calling each element by its key

    class elementSelector:
            def __init__(self) -&gt; None:
                self.webpage = webElements["webpage"]
                self.firstname = webElements["First_Name"]
                self.lastname = webElements["Last_Name"]
                self.email = webElements["E-Mail"]
                self.telephone = webElements["Telephone"]
                self.password = webElements["Password"]
                self.confirmpassword = webElements["Confirm_Password"]
                self.subscribe = webElements["Subscribe"]
                self.privacypolicy = webElements["Privacy_Policy"]
                self.submit = webElements["Submit"]
                self.todashboard = webElements["Continue"]

Then we declare them as methods of the elementSelector class like so:

    def webPage(self):
                return self.webpage
            def firstName(self):
                return self.firstname
            def lastName(self):
                return self.lastname
            def eMail(self):
                return self.email
            def Telephone(self):
                return self.telephone
            def Password(self):
                return self.password
            def confirmPassword(self):
                return self.confirmpassword
            def Subscribe(self):
                return self.subscribe  
            def privacyPolicy(self):
                return self.privacypolicy
            def Submit(self):
                return self.submit
            def goToDashboard(self):
                return self.todashboard

FileName — testScripts / singleSignupScript.py:

The singleSignupScript.py file contains the test event methods. We start by importing the built-in modules:

   from playwright.sync_api import sync_playwright
        import sys

The **sys **package connects the Python files in different folders and makes imported custom modules visible:

   sys.path.append(sys.path[0] + “/..”)

The directory path (“/..”) is a file-level declaration, showing that the imported module is two steps away from the root folder. So it might change in your case, depending on your project structure.

After this, we import and instantiate the elementSelector and testCapability classes from their respective modules:

    from elementSelectors.registrationPageSelectors import elementSelector
        from testCapabilities.testCaps import testCapabilities

        select = elementSelector()

        capability = testCapabilities()

So, for instance, to call the Chrome method from the testCapability class:

    capability.Chrome()

And to get a method, say the webPage from the elementSelector class:

    select.webPage()

To start the **Register **class, it inherits the Playwright package methods:

def __init__(self, playwright) -&gt; None:

However, to initiate the Register **class, we connected to the Chrome method (which defines the grid URL and the JSONified capabilities). The **self.page attribute is an instance of the browser context containing the locator actions.

    self.browser = playwright.chromium.connect(capability.Chrome())
                page = self.browser.new_page()
                self.page = page

The launchWeb **method opens the website using the page instance **goto **method by calling the website URL with the **select.webPage() instance of the **elementSelector **class:

    def launchWeb(self):
                self.page.goto(select.webPage())
                title = self.page.title()
                print(title)

Each of the other attributes in the class gets the appropriate method similarly. For readability, each field element accepts a **data **keyword.

For example, to fill in the first name:

   def fillFirstName(self, data):
                self.page.locator(select.firstName()).fill(data)

The elements that accept a click event doesn’t take any data. To click the Subscribe button, for instance:

   def subscribe(self):
                self.page.locator(select.Subscribe()).click()

The set_test_status **function at the top of the script returns test status on the LambdaTest Grid UI. So once a test passes, it returns **passed, but you get a **failed **message for failed tests:

    def set_test_status(page, status, remark):
                page.evaluate("_ =&gt; {}",
                "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

This later becomes a part of the **Register** class methods:

    def getSuccessStatus(self):
                return set_test_status(self.page, "passed", "Success")

            def getFailedStatus(self):
                return set_test_status(self.page, "failed", "Test failed")

FileName — testScenario / singleSignupRun.py:

The singleSignupRun.py file also starts with module imports. But notably, we imported the Register **class from the **singleSignupScript **module. We then created an event loop using the sync class of Playwright and passed this as **playwright:


    with sync_playwright() as playwright:

Remember that the **Register **class inherited the Playwright method earlier. To actualize this, we pass the **playwright **variable as an instance of the **Register **class. And it also now bears the inherited Playwright sync class:

    playwright = Register(playwright)

Therefore, the event loop executes the registration test steps in this order:

Step 1: Launch the test website using the launch method:

    playwright.launchWeb()

Step 2: Fill out the registration form. So for form fields, you must call and fill them since they accept a positional data argument:

    playwright.fillFirstName("Idowu")
                playwright.fillLastName("Omisola")
                playwright.fillEmail("anEmailgmai@gmail.com")
                playwright.fillPhone("08122334433")
                playwright.fillPassword("mypassword")
                playwright.confirmPassword("mypassword")
                playwright.subscribe()
                playwright.acceptPolicy()

Step 3: Submit the registration form:


    playwright.submit()

Step 4: Visit your dashboard for the first time:

   playwright.continueToDashboard()

The getSuccessStatus() method returns a passed message on the grid if the code in the try block executes successfully:

 playwright.getSuccessStatus()

Otherwise, it runs the getfailedStatus() method and returns a **failed **message on the grid:

    except Exception as err:
                playwright.getFailedStatus()

Finally, we close the browser outside the try-except block to prevent an endless loop, which throws an error during execution:

    playwright.closeBrowser()

Playwright Python Execution:

Run the test runner file (singleSignupRun.py):

 python singleSignupRun.py

The test executes successfully on the LambdaTest grid as shown below:

Check this out: Cross Browser Test Cloud- Browser & app testing cloud to perform both exploratory and automated testing across 3000+ different browsers, real devices and operating systems.

Login and Product Purchase Test Case Implementation:

The element selectors for the login test case are inside the loginAndBuySelectors.py file.

*FileName *—elementSelectors/loginAndBuySelectors.py

   webElements = {
        'webpage': "https://ecommerce-playground.lambdatest.io/index.php?route=account/login",
        'E-Mail': 'input[placeholder="E-Mail Address"]',
        'Password': 'input[placeholder="Password"]',
        'Login': 'input:has-text("Login")',
        'Search': 'input[name="search"] >> nth = 0',
        'searchbutton': 'div[class="search-button"]:has-text("Search")',
        'product': 'h4[class="title"]:has-text("Nikon D300") >> nth = 0',
        'addcart': 'div[id="entry_216842"]:has-text("Add to Cart")',
        'checkoutmodal': 'div[role="alert"]:has-text("Checkout")',
        'Hoverable': 'a[role="button"]:has-text("My account")',
        'Logout': 'span:has-text("Logout")'
    }

    class elementSelector:
        def __init__(self) -> None:
            self.webpage = webElements['webpage']
            self.email = webElements['E-Mail']
            self.password = webElements['Password']
            self.login = webElements['Login']
            self.hover = webElements['Hoverable']
            self.searchproduct = webElements['Search']
            self.product = webElements['product']
            self.addcart = webElements['addcart']
            self.checkout = webElements['checkoutmodal']
            self.searchbutton = webElements['searchbutton']
            self.logout = webElements['Logout']
        def webPage(self):
            return self.webpage
        def eMail(self):
            return self.email
        def Password(self):
            return self.password
        def loginAccount(self):
            return self.login
        def hoverBox(self):
            return self.hover
        def searchProduct(self):
            return self.searchproduct
        def Product(self):
            return self.product
        def addCart(self):
            return self.addcart
        def checkOut(self):
            return self.checkout
        def searchButton(self):
            return self.searchbutton
        def logoutUser(self):
            return self.logout

*FileName *—testScripts / singleLoginButScript.py:

   from playwright.sync_api import sync_playwright
    import sys
    sys.path.append(sys.path[0] + "/..")


    from elementSelectors.loginAndBuySelectors import elementSelector
    from testCapabilities.testCaps import testCapabilities

    select = elementSelector()

    capability = testCapabilities()

    # Setting grid status to failed or passed
    def set_test_status(page, status, remark):
            page.evaluate("_ => {}",
            "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

    class LoginAndBuy:

        def __init__(self, playwright) -> None:
            self.browser = playwright.chromium.connect(capability.Chrome())
            page = self.browser.new_page()
            self.page = page

        def launchWeb(self):
            self.page.goto(select.webPage())
            title = self.page.title()
            print(title)

        def fillEmail(self, data):
            self.page.locator(select.eMail()).fill(data)

        def fillPassword(self, data):
            self.page.locator(select.Password()).fill(data)

        def clickLogin(self):
            self.page.locator(select.loginAccount()).click()

        def fillSearchBox(self, data):
            self.page.locator(select.searchProduct()).fill(data)

        def clickSearchButton(self):
            self.page.locator(select.searchButton()).click()

        def clickProduct(self):
            self.page.locator(select.Product()).click()

        def clickAddToCart(self):
            self.page.locator(select.addCart()).click()

        def clickCheckOutModal(self):
            self.page.locator(select.checkOut()).click()

        def hoverMenuBox(self):
            self.page.locator(select.hoverBox()).hover()

        def clickLogout(self):
            self.page.locator(select.logoutUser()).click()

        def getSuccessStatus(self):
            set_test_status(self.page, "passed", "Success")

        def getFailedStatus(self):
            set_test_status(self.page, "failed", "Test failed")

        def closeBrowser(self):
            self.browser.close()

*FileName *—testScenarios / singleLoginBuyRun.py:

    import sys
    sys.path.append(sys.path[0] + "/..")

    from testScripts.singleLoginBuyScript import LoginAndBuy
    from playwright.sync_api import sync_playwright


    with sync_playwright() as playwright:
        try:
            playwright = LoginAndBuy(playwright)
            playwright.launchWeb()
            playwright.fillEmail("anEmailgmai@gmail.com")
            playwright.fillPassword("mypassword")
            playwright.clickLogin()
            playwright.fillSearchBox("Nikon")
            playwright.clickSearchButton()
            playwright.clickProduct()
            playwright.clickAddToCart()
            playwright.clickCheckOutModal()

            playwright.hoverMenuBox()
            playwright.clickLogout()
            playwright.getSuccessStatus()
        except:
            playwright.getFailedStatus()
        playwright.closeBrowser()

Playwright Python Code Walkthrough:

FileName — elementSelectors / loginAndBuySelectors.py:

As with the registration test case, we place all the login page element selectors and the website URL in a dictionary (webElements):

   webElements = {
            'webpage': "https://ecommerce-playground.lambdatest.io/index.php?route=account/login",
            'E-Mail': 'input[placeholder="E-Mail Address"]',
            'Password': 'input[placeholder="Password"]',
            'Login': 'input:has-text("Login")',
            'Search': 'input[name="search"] &gt;&gt; nth = 0',
            'searchbutton': 'div[class="search-button"]:has-text("Search")',
            'product': 'h4[class="title"]:has-text("Nikon D300") &gt;&gt; nth = 0',
            'addcart': 'div[id="entry_216842"]:has-text("Add to Cart")',
            'checkoutmodal': 'div[role="alert"]:has-text("Checkout")',
            'Hoverable': 'a[role="button"]:has-text("My account")',
            'Logout': 'span:has-text("Logout")'
        }

The Search *and **product **elements have the *>> nth = index because each of these DOM elements has an nth node with similar selectors. So the **nth **argument helps specify the index position of the children, starting from zero.

For example, to select the first product from a group of similar ones as we did above:

    ‘product’: ‘h4[class=”title”]:has-text(“Nikon D300”) &gt;&gt; nth = 0’

We use these elements to initiate the **elementSelector **class by attaching each to an attribute:

   class elementSelector:
            def __init__(self) -&gt; None:
                self.webpage = webElements['webpage']
                self.email = webElements['E-Mail']
                self.password = webElements['Password']
                self.login = webElements['Login']
                self.hover = webElements['Hoverable']
                self.searchproduct = webElements['Search']
                self.product = webElements['product']
                self.addcart = webElements['addcart']
                self.checkout = webElements['checkoutmodal']
                self.searchbutton = webElements['searchbutton']
                self.logout = webElements['Logout']

Next, we create a method that returns each attribute. These methods will handle Playwright locator events in the test script:

   def webPage(self):
                return self.webpage
            def firstName(self):
                return self.firstname
            def lastName(self):
                return self.lastname
            def eMail(self):
                return self.email
            def Telephone(self):
                return self.telephone
            def Password(self):
                return self.password
            def confirmPassword(self):
                return self.confirmpassword
            def Subscribe(self):
                return self.subscribe  
            def privacyPolicy(self):
                return self.privacypolicy
            def Submit(self):
                return self.submit
            def goToDashboard(self):
                return self.todashboard

So, the above block attaches each attribute to the **elementSelector **class method. We can use these easily in another file; you only have to call each from an instance of the **elementSelector **class. That’s one of the strong points of the Page Object Model (POM).

FileName — testScripts / singleLoginBuyScript.py:

We start the singleLoginButScript.py file by importing the synchronous Playwright and sys packages. Then we use the sys append method to point Python to the system path before importing our custom modules (elementSelector and testCapabilities):

    from playwright.sync_api import sync_playwright
        import sys
        sys.path.append(sys.path[0] + "/..")

        from elementSelectors.loginAndBuySelectors import elementSelector
        from testCapabilities.testCaps import testCapabilities

We create an instance of the elementSelector and testCapabilities classes to prevent conflict with the class inheritance:

   select = elementSelector()

        capability = testCapabilities()

It’s now easy to call each method from these classes via their object instance. We leverage this to declare our methods in the LoginAndBuy class, starting with initialization with the Chrome browser context. However, the initialization inherits the Playwright class:

   class LoginAndBuy:

            def __init__(self, playwright) -&gt; None:
                self.browser = playwright.chromium.connect(capability.Chrome())
                page = self.browser.new_page()
                self.page = page

In the above snippet, capability.Chrome() picks the Chrome() method from the testCapabilities class. You can change this to Microsoft Edge by replacing Chrome() with the Edge() method:

   self.browser = playwright.chromium.connect(capability.Edge())

The other methods belong to the elementSelector **class. So the test case starts by launching the browser using the inherited browser context. Note how it selects the **webPage() method from this class:

    def launchWeb(self):
                self.page.goto(select.webPage())

The following three methods define the login process. Each form field accepts a data keyword (the Email and password registered earlier):

Below are the login steps:


    def fillEmail(self, data):
                self.page.locator(select.eMail()).fill(data)

            def fillPassword(self, data):
                self.page.locator(select.Password()).fill(data)

            def clickLogin(self):
                self.page.locator(select.loginAccount()).click()

Next up, we search for a product, select it when found, then add it to the cart and checkout:

  def fillSearchBox(self, data):
                self.page.locator(select.searchProduct()).fill(data)

            def clickSearchButton(self):
                self.page.locator(select.searchButton()).click()

            def clickProduct(self):
                self.page.locator(select.Product()).click()

            def clickAddToCart(self):
                self.page.locator(select.addCart()).click()

            def clickCheckOutModal(self):
                self.page.locator(select.checkOut()).click()

The final test step is to log out of the website. The hover() event makes the logout button accessible since it’s in a hoverable dropdown:

  def hoverMenuBox(self):
                self.page.locator(select.hoverBox()).hover()

            def clickLogout(self):
                self.page.locator(select.logoutUser()).click()

The **set_test_status **function at the top of the script helps communicate the test status to the cloud grid’s UI:

    def set_test_status(page, status, remark):
                page.evaluate("_ =&gt; {}",
                "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

This becomes part of the **LoginAndBuy **class methods:

    def getSuccessStatus(self):
                set_test_status(self.page, "passed", "Success")

            def getFailedStatus(self):
                set_test_status(self.page, "failed", "Test failed")

Finally, we close the browser context:

    def closeBrowser(self):
                self.browser.close()

FileName — testScenarios / singleLoginBuyRun.py:

The singleLoginBuyRun.py file runs the login and product purchase test case. First, we import the Playwright sync module and resolve the system path using the sys package:

    import sys
        sys.path.append(sys.path[0] + "/..")

        from playwright.sync_api import sync_playwright

We also have to import the **LoginAndBuy **class:

    from testScripts.singleLoginBuyScript import LoginAndBuy

Next is the class instance declaration inside the Playwright event loop, followed by website launch on the selected browser:

  with sync_playwright() as playwright:
            try:
                playwright = LoginAndBuy(playwright)
                playwright.launchWeb()

The following steps occur within the event loop:

Step 1: Log in another time with the registered account. Below are the login steps declaration within the event loop:

       playwright.fillEmail("anEmailgmai@gmail.com")
                playwright.fillPassword("mypassword")
                playwright.clickLogin()

Step 2: Search for a product and go to the product page:

    playwright.fillSearchBox("Nikon")
                playwright.clickSearchButton()

Step 3: Select the item you searched to go to the product page:

   playwright.clickProduct()

Step 4: Add the selected product to the cart:

    playwright.clickAddToCart()

Step 5: Check out with the purchased product:

 playwright.clickCheckOutModal()

Step 6: The event loop ends with the logout steps. The success status must be within the try clause since it runs only if the series of code in the try block work:

    playwright.hoverMenuBox()
                playwright.clickLogout()
                playwright.getSuccessStatus()

Otherwise, the failed status only runs if there’s an exception:

   except:

       playwright.getFailedStatus()

Finally, we close the browser regardless of what happens in the event loop:

   playwright.closeBrowser()

Execution of the Login and Product Purchase Test on the Cloud Grid:

To execute this test case:

  python singleLoginBuyRun.py

The test runs successfully on the cloud grid as shown:

Check this out: Test on Safari Browser Online with Real Mac Machines. Test on Latest Safari Desktop and Mobile Browsers for Cross Browser Compatibility.

Implementing parallel testing with Playwright Python

Performing cross-browser regression testing for multiple browsers at once helps find issues faster, allowing you to move on to other work. We will continue to maintain the same browser configurations for the parallel test for testing efficiency purposes.

Running the test cases in parallel on the cloud grid helps you simulate an instance of servers in the cloud where you can run your test cases concurrently on separate cloud host machines. This helps check if your app works as it should in different integration environments.

In this case, the parallel test concept is to iterate the test cases through a capabilities array. So for this section of this Playwright Python tutorial, we’ll run the registration and login tests on two browsing capabilities; Chrome and Microsoft Edge.

Note: The entire test suite shares the testCap.py file, which we’ve shown earlier. However, the selector modules (registrationPageSelectors.py and loginAndBuySelectors.py) also remain the same for the signup and login to purchase parallel test cases.

Registration Parallel Test Implementation:

**FileName *— testScripts/parallelSignup.py*

   from playwright.sync_api import sync_playwright
    import sys
    sys.path.append(sys.path[0] + "/..")


    from elementSelectors.registrationPageSelectors import elementSelector
    from testCapabilities.testCaps import testCapabilities

    select = elementSelector()

    capability = testCapabilities()

    def set_test_status(page, status, remark):
            page.evaluate("_ => {}",
            "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

    class Register:
        def __init__(self, playwright) -> None:
            self.allCaps = [capability.Edge(), capability.Chrome()]
            self.browsers = [playwright.chromium.connect(i) for i in self.allCaps]
            pages = [i.new_page() for i in self.browsers]
            self.pages = pages
        def launchWeb(self):
            for page in self.pages:
                page.goto(select.webPage())
                title = page.title()
                print(title)
        def fillFirstName(self, data):
            for page in self.pages:
                page.locator(select.firstName()).fill(data)
        def fillLastName(self, data):
            for page in self.pages:
                page.locator(select.lastName()).fill(data)
        def fillEmail(self, data):
            for page in self.pages:
                page.locator(select.eMail()).fill(data)
        def fillPhone(self, data):
            for page in self.pages:
                page.locator(select.Telephone()).fill(data)
        def fillPassword(self, data):
            for page in self.pages:
                page.locator(select.Password()).fill(data)
        def confirmPassword(self, data):
            for page in self.pages:
                page.locator(select.confirmPassword()).fill(data)
        def subscribe(self):
            for page in self.pages:
                page.locator(select.Subscribe()).click()
        def acceptPolicy(self):
            for page in self.pages:
                page.locator(select.privacyPolicy()).click()
        def submit(self):
            for page in self.pages:
                page.locator(select.Submit()).click()
        def continueToDashboard(self):
            for page in self.pages:
                page.locator(select.goToDashboard()).click()
        def getSuccessStatus(self):
            for page in self.pages:
                set_test_status(page, "passed", "Success")

        def getFailedStatus(self):
            for page in self.pages:
                set_test_status(page, "failed", "Test failed")

        def closeBrowser(self):
            for browser in self.browsers:
                browser.close()

**FileName *— testScenarios/parallelSignupRun.py*

    import sys
    sys.path.append(sys.path[0] + "/..")

    from testScripts.parallelSignup import Register
    from playwright.sync_api import sync_playwright


    with sync_playwright() as playwright:

        try:
            playwright = Register(playwright)
            playwright.launchWeb()
            playwright.fillFirstName("Idowu")
            playwright.fillLastName("Omisola")
            playwright.fillEmail("some7gmail@gmail.com")
            playwright.fillPhone("08122334433")
            playwright.fillPassword("mypassword")
            playwright.confirmPassword("mypassword")
            playwright.subscribe()
            playwright.acceptPolicy()
            playwright.submit()
            playwright.continueToDashboard()
            playwright.getSuccessStatus()
        except Exception as err:
            playwright.getFailedStatus()

        playwright.closeBrowser()

Playwright Python Code Walkthrough:

FileName — testScripts/parallelSignup.py:

We import the needed modules for the test at the top of the script:

    from playwright.sync_api import sync_playwright
        import sys

The sys module points Python to the root directory path. Then we import the elementSelector and testCapabilities classes:

    from elementSelectors.registrationPageSelectors import elementSelector
        from testCapabilities.testCaps import testCapabilities

Next is the object instance creation. The select variable is the elementSelector class instance, while capability holds the testCapabilities class instance:


    select = elementSelector()

        capability = testCapabilities()

We initiate the Register class as we did in the previous single tests. But this time, we insert the capability methods (Chrome() and Edge()) into a list — so we can iterate through each browser instance to spin up a cross-browser parallel test.

So notably within the init function:

    self.allCaps = [capability.Edge(), capability.Chrome()]

Next is an iteration of the browser contexts, ending with the self.pages inheriting the pages list:

    self.browsers = [playwright.chromium.connect(i) for i in self.allCaps]
                pages = [i.new_page() for i in self.browsers]
                self.pages = pages

The launchWeb() method also iterates through the browser contexts to launch the test website in each browser. We then print out the title for each page:


    def launchWeb(self):
                for page in self.pages:
                    page.goto(select.webPage())
                    title = page.title()
                    print(title)

This iteration continues for every test method under the **Register **class:

  def fillFirstName(self, data):
                for page in self.pages:
                    page.locator(select.firstName()).fill(data)
            def fillLastName(self, data):
                for page in self.pages:
                    page.locator(select.lastName()).fill(data)
            def fillEmail(self, data):
                for page in self.pages:
                    page.locator(select.eMail()).fill(data)
            def fillPhone(self, data):
                for page in self.pages:
                    page.locator(select.Telephone()).fill(data)
            def fillPassword(self, data):
                for page in self.pages:
                    page.locator(select.Password()).fill(data)
            def confirmPassword(self, data):
                for page in self.pages:
                    page.locator(select.confirmPassword()).fill(data)
            def subscribe(self):
                for page in self.pages:
                    page.locator(select.Subscribe()).click()
            def acceptPolicy(self):
                for page in self.pages:
                    page.locator(select.privacyPolicy()).click()
            def submit(self):
                for page in self.pages:
                    page.locator(select.Submit()).click()
            def continueToDashboard(self):
                for page in self.pages:
                    page.locator(select.goToDashboard()).click()

We then defined the status methods to get the appropriate messages in the grid UI:

    def getSuccessStatus(self):
                for page in self.pages:
                    set_test_status(page, "passed", "Success")

            def getFailedStatus(self):
                for page in self.pages:
                    set_test_status(page, "failed", "Test failed")

The script ends by closing the browser context.

   def closeBrowser(self):
                for browser in self.browsers:
                    browser.close()

FileName — testScenarios / parallelSignupRun.py:

Nothing much has changed about the test runner file here. We import all the modules and point Python to the root directory, as we did earlier. However, this time, we import the Register class from the parallelSignup module since this is a parallel test:

    import sys
        sys.path.append(sys.path[0] + "/..")

        from testScripts.parallelSignup import Register
        from playwright.sync_api import sync_playwright

from playwright.sync_api import sync_playwright

The methods called under sync_playwright() event loop run the parallel signup test using the Register class instance (playwright):

    with sync_playwright() as playwright:

            try:
                playwright = Register(playwright)

The test steps haven’t changed. But this time, they run in parallel:

Step 1: Go to the registration page on both browser contexts in consideration:


    playwright.launchWeb()

Step 2: Filling of the registration form occurs in parallel on both browsers:

  playwright.fillFirstName("Idowu")
                playwright.fillLastName("Omisola")
                playwright.fillEmail("some7gmail@gmail.com")
                playwright.fillPhone("08122334433")
                playwright.fillPassword("mypassword")
                playwright.confirmPassword("mypassword")
                playwright.subscribe()
                playwright.acceptPolicy()

Step 3: Submit the form on both browsers:

    playwright.submit()

Step 4: Go to your dashboard for the first time. Then end the test execution with a status message on the grid UI (passed or failed):

    playwright.continueToDashboard()
                playwright.getSuccessStatus()
            except Exception as err:
                playwright.getFailedStatus()

Finally, call the closeBrowser() method to close all browser instances and end the test:

   playwright.closeBrowser()

Registration Parallel Test Execution:

Run the parallelSignupRun.py file:

   python parallelSignupRun.py

Our parallel cross-browser test cases run simultaneously on the LambdaTest cloud grid as shown:

Implementation (Login and Purchase use case):

**FileName *— testScripts / parallelLoginBuyScript.py*

    from playwright.sync_api import sync_playwright
    import sys
    sys.path.append(sys.path[0] + "/..")


    from elementSelectors.loginAndBuySelectors import elementSelector
    from testCapabilities.testCaps import testCapabilities

    select = elementSelector()

    capability = testCapabilities()

    # Setting grid status to failed or passed
    def set_test_status(page, status, remark):
            page.evaluate("_ => {}",
            "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

    class LoginAndBuy:


        def __init__(self, playwright) -> None:
            self.allCaps = [capability.Edge(), capability.Chrome()]
            self.browsers = [playwright.chromium.connect(i) for i in self.allCaps]
            pages = [i.new_page() for i in self.browsers]
            self.pages = pages

        def launchWeb(self):
            for page in self.pages:
                page.goto(select.webPage())
                title = page.title()
                print(title)

        def fillEmail(self, data):
            for page in self.pages:
                page.locator(select.eMail()).fill(data)

        def fillPassword(self, data):
            for page in self.pages:
                page.locator(select.Password()).fill(data)

        def clickLogin(self):
            for page in self.pages:
                page.locator(select.loginAccount()).click()

        def fillSearchBox(self, data):
            for page in self.pages:
                page.locator(select.searchProduct()).fill(data)

        def clickSearchButton(self):
            for page in self.pages:
                page.locator(select.searchButton()).click()

        def clickProduct(self):
            for page in self.pages:
                page.locator(select.Product()).click()

        def clickAddToCart(self):
            for page in self.pages:
                page.locator(select.addCart()).click()

        def clickCheckOutModal(self):
            for page in self.pages:
                page.locator(select.checkOut()).click()

        def hoverMenuBox(self):
            for page in self.pages:
                page.locator(select.hoverBox()).hover()

        def clickLogout(self):
            for page in self.pages:
                page.locator(select.logoutUser()).click()

        def getSuccessStatus(self):
            for page in self.pages:
                set_test_status(page, "passed", "Success")

        def getFailed(self):
            for page in self.pages:
                set_test_status(page, "failed", "Test failed")

        def closeBrowser(self):
            for browser in self.browsers:
                browser.close()

**FileName *— testScenarios / parallelLoginBuyRun.py:*

    import sys
    sys.path.append(sys.path[0] + "/..")

    from testScripts.parallelLoginBuyScript import LoginAndBuy
    from playwright.sync_api import sync_playwright


    with sync_playwright() as playwright:
        try:
            playwright = LoginAndBuy(playwright)
            playwright.launchWeb()
            playwright.fillEmail("some3gmail@gmail.com")
            playwright.fillPassword("mypassword")
            playwright.clickLogin()
            playwright.fillSearchBox("Nikon")
            playwright.clickSearchButton()
            playwright.clickProduct()
            playwright.clickAddToCart()
            playwright.clickCheckOutModal()

            playwright.hoverMenuBox()
            playwright.clickLogout()
            playwright.getSuccessStatus()
        except:
            playwright.getFailed()
        playwright.closeBrowser()

Playwright Python Code Walkthrough:

FileName — testScripts / parallelLoginBuyScript.py:

We start by importing all necessary modules for the test case inside the parallelLoginBuyScript.py file:

   from playwright.sync_api import sync_playwright
        import sys
        sys.path.append(sys.path[0] + "/..")

        from elementSelectors.loginAndBuySelectors import elementSelector
        from testCapabilities.testCaps import testCapabilities

Next is an instance of the elementSelector and testCapabilities classes:

  select = elementSelector()

        capability = testCapabilities()

We then set up the test status function to trigger failed or success messages on the cloud grid UI. Remember, we’ll implement this as a method of the loginAndBuy class:

    def set_test_status(page, status, remark):
                page.evaluate("_ =&gt; {}",
                "lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

The loginAndBuy inherits the Playwright class methods. As you can see, the init **function accepts an extra **playwright argument:


    class LoginAndBuy:
            def __init__(self, playwright) -&gt; None:

We have to iterate through the browser capabilities, then instantiate a browser context for each. Thus, the self.pages attribute inherits the pages list created from the loop:

    def __init__(self, playwright) -&gt; None:
                self.allCaps = [capability.Edge(), capability.Chrome()]
                self.browsers = [playwright.chromium.connect(i) for i in self.allCaps]
                pages = [i.new_page() for i in self.browsers]
                self.pages = pages

Next, we launch the test website on both browser contexts inside a loop:

   def launchWeb(self):
                for page in self.pages:
                    page.goto(select.webPage())
                    title = page.title()
                    print(title)

The rest of the methods in the class take an event handler, which we’ll run inside another file in an event loop:

  def fillEmail(self, data):
                for page in self.pages:
                    page.locator(select.eMail()).fill(data)

            def fillPassword(self, data):
                for page in self.pages:
                    page.locator(select.Password()).fill(data)

            def clickLogin(self):
                for page in self.pages:
                    page.locator(select.loginAccount()).click()

            def fillSearchBox(self, data):
                for page in self.pages:
                    page.locator(select.searchProduct()).fill(data)

            def clickSearchButton(self):
                for page in self.pages:
                    page.locator(select.searchButton()).click()

            def clickProduct(self):
                for page in self.pages:
                    page.locator(select.Product()).click()

            def clickAddToCart(self):
                for page in self.pages:
                    page.locator(select.addCart()).click()

            def clickCheckOutModal(self):
                for page in self.pages:
                    page.locator(select.checkOut()).click()

            def hoverMenuBox(self):
                for page in self.pages:
                    page.locator(select.hoverBox()).hover()

            def clickLogout(self):
                for page in self.pages:
                    page.locator(select.logoutUser()).click()

We also declare the test status functions as methods under the loginAndBuy class:

   def getSuccessStatus(self):
                for page in self.pages:
                    set_test_status(page, "passed", "Success")

            def getFailed(self):
                for page in self.pages:
                    set_test_status(page, "failed", "Test failed")

Finally, we iterate through the browser contexts to close the opened instances:

    def closeBrowser(self):
                for browser in self.browsers:
                    browser.close()

FileName — testScenarios / parallelLoginBuyRun.py:

We import all the essential packages in the parallel test runner file. However, the custom class of interest this time is loginAndBuy:

    import sys
        sys.path.append(sys.path[0] + "/..")

        from testScripts.parallelLoginBuyScript import LoginAndBuy
        from playwright.sync_api import sync_playwright

The playwright_sync event loop runs the parallel test case, starting with a playwright instance of the loginAndBuy class, followed by website launch on both browser contexts:


    with sync_playwright() as playwright:
            try:
                playwright = LoginAndBuy(playwright)
                playwright.launchWeb()

Step 1: Fill out the login form and sign in on both browser contexts considered for the parallel test:

    playwright.fillEmail("some3gmail@gmail.com")
        playwright.fillPassword("mypassword")
        playwright.clickLogin()

Step 2: Search for a product and click the search button:

 playwright.fillSearchBox("Nikon")
        playwright.clickSearchButton()

Step 3: Go to the product page by clicking it once found:

    playwright.clickProduct()

Step 4: Add the product to the cart by clicking the ADD TO CART button:

 playwright.clickAddToCart()

Step 5: Check out of the product page:

 playwright.clickCheckOutModal()

Step 6: Log out of the website and return a success status on the LambdaTest cloud grid UI:

   playwright.hoverMenuBox()
        playwright.clickLogout()
        playwright.getSuccessStatus()

If the test fails for whatever reason, the getFailed() method within the except block runs and returns a failed message on the grid UI:

    except:
                playwright.getFailed()

It’s also important to close the event loop for each browser context to prevent an endless loop. We do this outside the try-except block to avoid termination conflict:

  playwright.closeBrowser()

Execution of the Login and Purchase Parallel Test:

Run the parallelLoginBuyRun.py file.

python parallelLoginBuyRun.py

Below is the parallel test execution for the selected browser on the cloud grid:

Check this out: Test On Online Emulator Android- Test your web and mobile apps on Android Emulators online.

Conclusion

The Playwright testing framework provides simple methods for end to end testing. In this article, we demonstrated the use of Playwright Python for single and parallel testing. And we wrapped all our test cases inside the POM model for simplicity.

We started by exploring the power of Playwright’s code generator and how it can help us automatically create test case code and selectors. But since that method is complex and unscalable, we further implemented a single custom end to end Playwright test on user registration and product purchase on the LambdaTest e-commerce playground.

This led us to perform a cross-browser parallel test for a similar test scenario. And you’ve also seen how to create class methods that connect your tests to the LambdaTest cloud grid.