Blog

Step-by-Step Playwright Page Object Model Implementation Tutorial

by Chris Adams | Feb 20, 2024 | Automation Testing, Blog | 0 comments

Although Selenium is the most popular open-source tool for the automation testing of web applications, Playwright has been gaining much popularity as well. As the Page Object Model approach is widely used while creating test automation frameworks, we wanted to write an easy guide that can help everyone with the Playwright Page Object Model implementation. Being an experienced automation testing company, we started our test automation journey with Selenium. Since we’re always focused on being ahead of the curve, we have successfully implemented Playwright in numerous of our projects as well. So we will be exploring how to use Playwright effectively by applying Pages creation, Method implementation, and Locators.

Before heading to the Playwright Page Object Model Implementation, let’s see a brief intro of what it is, how it works, and the benefits it brings to the table.

What is the Page Object Model (POM)?

Page Object Model can be simply termed a design pattern that is used to improve the maintainability and reusability of your test automation scripts. It is achieved by encapsulating UI elements and interactions into separate classes called Page Objects.

How Does POM Work?

1.Page Objects: Each web page or component is represented by a Page Object, which contains the methods to interact with the elements on that page.

2.Reusable Components: Page Objects are designed for reuse across multiple test cases, reducing redundancy and promoting code efficiency.

3.Readability and Maintainability: Test scripts become more readable as they interact with the application through the methods provided by Page Objects. Additionally, maintenance becomes easier as changes to the UI are isolated within the corresponding Page Objects.

Benefits of Page Object Model:

Let’s take a look at the benefits we can reap by implementing the Page Object Model in Playwright or in general with any tool.

1. The Page Object Model facilitates the scaling of test suites by providing a structured approach to organizing test code.

2. By encapsulating UI interactions within Page Objects, changes to the UI can be made without impacting the entire test suite.

3. Page Objects can be reused across different test cases, promoting code efficiency and reducing duplication.

4. If there are any changes to the UI or even the functionality of a page, you only need to update the corresponding page object instead of modifying multiple test scripts, making maintenance easier.

Playwright Page Object Model Implementation:

To enable easy understanding, we have broken down the full process into small steps that you can follow. You can also quickly navigate through the blog by clicking on the specific step you need help with.

• Step 1: Install Node JS
• Step 2: Install the Required Libraries
• Step 3: Install Cucumber
• Step 4: Create the Configuration File
• Step 5: Create a New Feature File
• Step 6: Create a Step Definition
• Step 7: Playwright POM Implementation

Step 1: Install Node JS

1. Download Node.js and install it by following the specified instructions.

2. Once installed, open a terminal or command prompt.

3. Type node -v and press Enter to check if Node.js is installed correctly. If it has been installed correctly, you should see the version number.

Step 2: Install the Required Libraries

As a next step in our Playwright Page Object Model implementation, you have to install the following libraries using Node Package Manager.

npm i -D @playwright/test
npm i -D playwright 
npx playwright install

Note: Make sure to run this command in your project root directory.

Step 3: Install Cucumber

We generally follow the BDD approach as we’ve always found it to be the most effective while collaborating with our clients. And the BDD tool of our choice is Cucumber. You can install it using the below command.

npm i -D @cucumber/[email protected] @cucumber/pretty-formatter

After executing this command, the ‘package.json’ file will be updated to include the dependencies as shown below.

Note: Extensions such as ‘Cucumber’, ‘Cucumber (Gherkin)’, and ‘Playwright tests’ for VS Code need to be added. Please refer to the attached screenshot below.

Step 4: Create the Configuration File

Now that all the setup and prerequisite steps of the Playwright Page Object Model implementation are done, let’s see how to create the configuration file. The configuration file named cucumber.conf.js at the root level of the project is required to run our test script using Cucumber. You can use the below code to create it.

Code:

const { Before, BeforeAll, AfterAll, After, setDefaultTimeout } = require("@cucumber/cucumber");
const { chromium } = require("playwright");
const fs = require('fs');
setDefaultTimeout(60000); //Default timeout
// Launch the browser
BeforeAll(async function () {
    global.browser = await chromium.launch({
        headless: false,
        slowMo: 1000,
        browserContextOptions: {
            viewport: null,
        },
    });
    const context = await browser.newContext();
    page = await context.newPage();
});


// Quit the browser
AfterAll(async function () {
    await global.browser.close();
});


// Take a screenshot for each scenario
After(async function (testCase) {
    const screenshotPath = `screenshots/${Date.now()}_${testCase.result.status}.png`;
    await global.page.screenshot({ path: screenshotPath });
});

In the provided code snippet, we’ve implemented the browser configuration setup along with hook concepts. By using the ‘BeforeAll’ annotation, the browser will be launched and made available for the entire execution. Once the execution is complete, the browser will be closed according to the configuration set in the ‘AfterAll’ hooks.

Step 5: Creating a New Feature File

The next step in our Playwright Page Object Model implementation is to create a new feature file. First, you have to create a file named DemoLogin.feature within the ‘tests/acceptance/features’ directory as shown below.

Since we’re following the BDD approach, we’ll start by creating a feature file in the Gherkin language.

Here’s a simple syntax example of what a feature file looks like:

Step 6: Creating a Step Definition

Next up, we have to create a Step Definition in our Playwright Page Object Model implementation process. We need to create a Context file named DemoLoginSteps.js inside the tests/acceptance/stepDefinitions directory using the below command,

npm run test:e2e tests/acceptance/features/DemoLogin.feature

Note: It will be generate the step definition

Using above-mentioned snippet, we will add steps in the DemoLoginStep.js file

We have to create a context file named DemoLoginSteps.js inside the tests/acceptance/stepDefinitions directory and add it to the following script in your package.json file.

“–require tests/acceptance/stepdefinitions/*.js” specifies that the test should require all JavaScript files (*.js) in the tests/acceptance/stepdefinitions/ directory. These are the likely step definition files that define the behavior of the steps in the Cucumber scenarios.

Step 7: Playwright POM Implementation

Now we’re at the final stage of the Playwright Page Object Model implementation process.

• First up, create a folder named “pages” at the project level.
• Use this folder to store classes or modules that represent various web pages or components within an application.
• Inside this “pages” folder, create .js files named loginPage.js, and homePage.js</> for better clarity.
• These files encapsulate the functionality and elements specific to the respective pages, facilitating easier interaction and testing of the functionality.

Define the web elements and Methods for the two pages we’ve created (i.e.) LoginPage and HomePage.

In the above snippet, we are maintaining the web elements in the Loginpage.js file.

We’ve created test scripts as functions and now we want to use these functions in our step definitions. We’ve also defined our web pages using the ‘require’ keyword in Step definition. Additionally, we’re using a page instance to ensure that the browser instance is shared across all pages.

So we have implemented the Playwright Page Object Model for the Login and Home Page by specifying the methods and objects in the js files.

Execute the test scripts specifically for a feature file named DemoLogin.feature, which is located in the tests/acceptance/features/ directory by using the below-mentioned command.

<npm run test:e2e tests/acceptance/features/DemoLogin.feature

Note: The browser will open and execute all the scenarios defined in the feature file.

Conclusion:

We hope you now have a clear understanding of the Playwright Page Object Model implementation by adhering to best practices and design patterns. We’ve additionally explored the advantages of utilizing the Page Object Model (POM). If the process of adding new scripts is time-consuming, it could indicate a lack of reusable scripts or that you’re in the initial stages of implementing automation testing for your project. Being a leading test automation service provider, we always implement the Page Object Model in our projects and hope you will do so as well.

Playwright Cross-browser Testing Tutorial

by Anika Chakraborty | Jan 9, 2024 | Automation Testing, Blog | 0 comments

Playwright is a robust tool that automates cross-browser testing across Chromium, Firefox, and WebKit using a single API. It is an open source software developed and launched by Microsoft in 2020 and quickly gained popularity. Cross-browser testing using Playwright is a seamless process that enables efficient testing to identify and address potential issues, guaranteeing a seamless user experience. Being an Automation Testing company, we have hands-on experience using Playwright for cross-browser testing. So, in our Playwright cross-browser testing tutorial blog, we’ll be explaining how to set up and run test scripts for different browsers in Playwright.

Why is Cross-Browser Testing Needed?

Cross-browser testing is pivotal to ensure web applications work efficiently across different browsers. Users access our website or web application on a diverse landscape of browsers and it’s crucial that our platform performs well on their preferred browser. If our site fails to function adequately, they may switch to a competitor’s website instead.

In Carrie Ryan’s words, “Survivors aren’t always the strongest; sometimes they’re the smartest”.

Effective cross browsing testing makes our website or application the smartest in the ecosystem. It helps maintain consistency in the user interface and prevents issues like broken layouts or non-functional features. Missing out on supporting a major browser can result in losing a significant portion of the potential user base.

Why Playwright?

Playwright is a Node.js library and many testers consider it to be a reliable framework for its multi-browser support, web-first assertions, unified API, built-in reports, and parallel test execution capabilities. It has remarkably advanced features and is notable for its concise syntax and execution speed. And like Selenium, Playwright facilitates the use of multiple languages including TypeScript, JavaScript, Python, .NET, and Java. Playwright cross-browser testing helps deliver a high-quality web experience due to its benefits such as early issue detection, regulatory compliance, and performance optimization.

List of Supported Browsers:

• Google Chrome
• Safari
• Firefox

Tutorial to setup Playwright for Cross-Browser Testing

In order to help you navigate through the blog with ease, we have segregated the Playwright cross-browser testing tutorial as shown below,

• How to Install and Run Playwright Cross-Browser Test Script
• Running Test Scripts on Multiple Browsers
• Running Test Scripts in a Particular Browser
• Alternate approach to run the test in different browsers
• Creating a Cross-Browser Testing Function

How to Install and Run Playwright Cross-Browser Test Script

First up, let’s find out how you can install and run Playwright.

Step 1:

Create a demo folder and open it in VS Code.

Step 2:

Install Playwright by entering the below command in that particular folder.

<npm init playwright@latest>

Step 3:

Once Playwright is installed, you will see a project structure that you can use to run test scripts on multiple browsers.

Running Test Scripts on Multiple Browsers

Now that we are all set, let’s find out how we can run the test scripts on multiple browsers at once in our Playwright cross-browser testing tutorial.

Step 1:

Open the playwright.config.js file in the project structure. Ensure that different browsers are configured by default in the playwright.config.js file.

Step 2:

Run an example test in the tests folder using the below command

<npx playwright test>

It will execute the tests in different browsers that are configured in the playwright.config.jsfile.

Step 3:

After the tests have been executed, you can see the report by executing the following command

<npx playwright show-report>

Running Test Scripts in a Particular Browser

Apart from running the test scripts in multiple browsers, you’ll also face the need to run your test scripts on a particular browser. And that is what we’ll be covering now in our Playwright cross-browser testing tutorial.

Chrome:

Run the below command to execute the tests in the Chrome browser

<npx playwright test --project=chromium>

You can view the report by executing the below command

<npx playwright show-report>

Firefox:

Run the below command to execute the tests in the Firefox browser

<npx playwright test --project=firefox>

You can view the report by executing the specified command

<npx playwright show-report>

Safari:

Run the below command to execute the tests in the Safari browser

<npx playwright test --project=webkit>

You can view the report by executing the mentioned command

<npx playwright show-report>

Alternate approach to run the test in different browsers

There is also an alternative approach you can follow to achieve Playwright Cross-browser testing. All you have to do is Click on TEST EXPLORER -> Click the drop down icon on the Run Test button. Here you will find different browsers to execute the test.

If you click on any of the browsers listed, the test will be executed on that particular browser. We can also change the default browser by clicking the Select Default Profile and choosing the default browser from the list.

Launching Different Browsers using Code

Playwright supports testing on Chromium, Firefox, and WebKit-powered browsers. You can launch different browsers by importing the respective browser classes from Playwright:

<const { chromium, firefox, webkit } = require("playwright");>

To launch a specific browser, use the launch() method:

<const browser = await chromium.launch();>

Replace Chromium with Firefox or Webkit to launch Firefox or WebKit browsers.

Creating a Cross-Browser Testing Function

Now that we know how to launch different browsers, let’s create a function that accepts a website URL and tests it across multiple browsers in our Playwright cross-browser testing tutorial. This function launches each browser, navigates to the specified website URL, and runs the tests or assertions.

<const { chromium, firefox, webkit } = require("playwright");
const testOnAllBrowsers = async (websiteUrl) => {
 const browsers = [chromium, firefox, webkit];
 for (const browserType of browsers) {
   const browser = await browserType.launch();
   const context = await browser.newContext();
   const page = await context.newPage();
   await page.goto(websiteUrl);
   // Perform your tests/assertions here
   // ...
   await browser.close();
 }
};
>

Note: Remember to close the browser using browser.close() after you finish your tests.

Conclusion

Playwright offers a seamless way to assess the website’s performance across various browsers and viewport dimensions. Through the automation capabilities and advanced features provided by Playwright, you can streamline the testing procedure, guaranteeing a uniform user experience and identifying potential issues early in the development cycle. We hope you now have a clear understanding of how to perform Playwright cross-browser testing and found value in reading our blog. Stay connected to our space for more such informative software testing content.

A Conclusive Allure Report Tutorial with Sample Report

by Mollie Brown | Mar 16, 2023 | Automation Testing, Blog | 19 comments

In our Allure Report Tutorial, we will be explaining the steps to generate an Allure report and show you the different features that are available as reporting is an integral part of every automation testing framework. Without proper reports, you will not be able to analyze the results of your execution and take further action. Though automation tests are created and executed by people with technical knowledge, the people who read the reports may not possess too much technical knowledge. So it is important for reports to be visually strong and easy to understand.

We have chosen Allure as it is an open-source test reporting tool that can be used to represent the results of your test execution concisely in the form of interactive and comprehensive web reports. We also have first-hand experience in using Allure reports to create top-notch reports while delivering high-quality automation testing services to our clients. So using that experience, we have created and used a sample report in our Allure Report tutorial to make it easier for you to understand.

Allure Report Tutorial

You’d have to follow the below-mentioned installation steps if you haven’t yet installed Allure on your computer. If you already have Allure installed and are aware of the dependencies, you can directly proceed further in our Allure Report Tutorial. We have listed the important annotations you’ll have to know, defined the project structure, and provided the code snippets you can use to create your Allure report.

Installation & Set up

1. Download the latest version as a zip archive from Github Releases.

2. Unpack the archive to the allure-commandline directory.

3. Navigate to the bin directory.

4. Use allure.bat for Windows or allure for Unix platforms.

5. Add allure to the system PATH.

Note: Allure CLI requires Java Runtime Environment to be installed.

Add the Dependencies & Run

• Update the Properties section in the Maven pom.xml file
• Add Selenium, JUnit4 and Allure-JUnit4 dependencies in POM.xml
• Update Build Section of pom.xml in Allure Report Project.
• Create Pages and Test Code for the pages

Once you have completed all the above steps, you can run the test and generate your Allure Report by following the steps mentioned later on in our Allure report tutorial. Now let’s take a look at the code for your POM.xml file.

Pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>org.example</groupId>
   <artifactId>Selenium-Allure-Demo</artifactId>
   <version>1.0-SNAPSHOT</version>

   <properties>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <selenium.version>3.141.59</selenium.version>
       <testng.version>7.4.0</testng.version>
       <allure.testng.version>2.14.0</allure.testng.version>
       <maven.compiler.plugin.version>3.5.1</maven.compiler.plugin.version>
       <maven.compiler.source>8</maven.compiler.source>
       <maven.compiler.target>8</maven.compiler.target>
       <aspectj.version>1.9.6</aspectj.version>
       <maven.surefire.plugin.version>3.0.0-M5</maven.surefire.plugin.version>
   </properties>

   <build>

       <plugins>
           <!-- Compiler plug-in -->

           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-compiler-plugin</artifactId>
               <version>${maven.compiler.plugin.version}</version>
               <configuration>
                   <source>${maven.compiler.source}</source> <!--For JAVA 8 use 1.8-->
                   <target>${maven.compiler.target}</target> <!--For JAVA 8 use 1.8-->
               </configuration>
           </plugin>

           <!-- Added Surefire Plugin configuration to execute tests -->
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-surefire-plugin</artifactId>
               <version>${maven.surefire.plugin.version}</version>
               <configuration>
                   <suiteXmlFiles>
                       <suiteXmlFile>TestNG.xml</suiteXmlFile>
                   </suiteXmlFiles>
                   <argLine>
                       -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                   </argLine>
               </configuration>
               <dependencies>

                   <!-- https://mvnrepository.com/artifact/org.aspectj/aspectjweaver -->
                   <dependency>
                       <groupId>org.aspectj</groupId>
                       <artifactId>aspectjweaver</artifactId>
                       <version>${aspectj.version}</version>
                   </dependency>
               </dependencies>
           </plugin>
       </plugins>
   </build>
   <dependencies>

       <!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
       <dependency>
           <groupId>org.seleniumhq.selenium</groupId>
           <artifactId>selenium-java</artifactId>
           <version>${selenium.version}</version>
       </dependency>

       <!-- https://mvnrepository.com/artifact/org.testng/testng -->
       <dependency>
           <groupId>org.testng</groupId>
           <artifactId>testng</artifactId>
           <version>${testng.version}</version>
           <scope>test</scope>
       </dependency>

       <!-- https://mvnrepository.com/artifact/io.qameta.allure/allure-testng -->
       <dependency>
           <groupId>io.qameta.allure</groupId>
           <artifactId>allure-testng</artifactId>
           <version>${allure.testng.version}</version>
           <scope>test</scope>
       </dependency>
   </dependencies>

</project>

Project structure with Allure Report:

In our Allure report tutorial, we have basically kept two packages called ‘pages’ and ‘tests’. The pages package will include all the pages you want to test and the tests package will include the different tests that you want to perform.

Pages Package:

There are two pages that we have added to our package, and they are the Dashboard page and the Login page.

Dashboard page:

package AllureDemo.pages;

import io.qameta.allure.Step;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.testng.Assert;

public class DashboardPage {

   WebDriver driver;

   By dashboardPageTitle = By.xpath("(//span[.='Dashboard'])[1]");

   By options = By.xpath(
           "//div[@title='Assign Leave']");

   public DashboardPage(WebDriver driver) {
       this.driver = driver;

   }

   @Step("Verify title of Dashboard page")
   public void verifyDashboardPageTitle() {
       String DashboardPageTitle = driver.findElement(dashboardPageTitle).getText();
       Assert.assertTrue(DashboardPageTitle.contains("Dashboard"));
   }

   @Step("Verify Quick Launch Options on Dashboard page")
   public void verifyQuickLaunchOptions() {
       String QuickLaunchOptions = driver.findElement(options).getAttribute("title");
       Assert.assertTrue(QuickLaunchOptions.contains("Assign Leave"));
   }

}

Login page:

package AllureDemo.pages;

import io.qameta.allure.Step;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.testng.Assert;

public class LoginPage {

   WebDriver driver;

   By userName = By.name("username");

   By password = By.name("password");

   By titleText = By.name("username");

   By login = By.xpath("//button[@type='submit']");

   By errorMessage = By.xpath("//p[.='Invalid credentials']");

   public LoginPage(WebDriver driver) {
       this.driver = driver;
   }

   // Set user name in the textbox
   public void setUserName(String strUserName) {
       driver.findElement(userName).sendKeys(strUserName);
   }

   // Set password in the password textbox
   public void setPassword(String strPassword) {
       driver.findElement(password).sendKeys(strPassword);
   }

   // Click the login button
   public void clickLogin() {
       driver.findElement(login).click();
   }

   @Step("Verify title of Login Page")
   public void verifyPageTitle() {
       String loginPageTitle = driver.findElement(titleText).getAttribute("name");
       Assert.assertTrue(loginPageTitle.contains("username"));
   }

   /* Failed Test */
   @Step("Verify error message when invalid credentail is provided")
   public void verifyErrorMessage() {
       String invalidCredentialErrorMessage = driver.findElement(errorMessage).getText();
       Assert.assertTrue(invalidCredentialErrorMessage.contains("Invalid credentials"));
   }

   @Step("Enter username and password")
   public void login(String strUserName, String strPasword) {

       // Fill in the user name
       this.setUserName(strUserName);

       // Fill in the password
       this.setPassword(strPasword);

       // Click the Login button
       this.clickLogin();

   }
}

Tests Package:

For our Allure Report tutorial, we have added 3 tests by the names base test, dashboard test, and login test. Let’s take a look at the code snippets for each of these tests below.

Base test:

package AllureDemo.tests;

import AllureDemo.pages.DashboardPage;
import AllureDemo.pages.LoginPage;
import io.qameta.allure.Step;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.AfterClass;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.BeforeMethod;

import java.util.concurrent.TimeUnit;

public class BaseTest {

   public static WebDriver driver;
   LoginPage objLogin;
   DashboardPage objDashboardPage;

   @Step("Start the application")
   @BeforeMethod
   public void setup() {
       System.setProperty("webdriver.chrome.driver",
               "C:\\Users\\Codoid\\Documents\\QA-SAM-March2023-Stories\\resources\\drivers\\chromedriver_win.exe");
       driver = new ChromeDriver();
       driver.manage().window().maximize();
       driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
       driver.get("https://opensource-demo.orangehrmlive.com/");
   }

   @Step("Stop the application")
   @AfterMethod
   public void close() {
       driver.close();
   }
}

DashboardTests

package AllureDemo.tests;

import AllureDemo.pages.DashboardPage;
import AllureDemo.pages.LoginPage;
import io.qameta.allure.*;
import org.testng.ITestNGListener;
import org.testng.annotations.Listeners;
import org.testng.annotations.Test;

@Epic("Web Application Regression Testing")
@Feature("Dashboard Page Tests")
@Listeners(TestExecutionListener.class)
public class DashboardTests extends BaseTest {

   LoginPage objLogin;
   DashboardPage objDashboardPage;

   @Severity(SeverityLevel.BLOCKER)
   @Test(priority = 0, description = "Verify Dashboard Page")
   @Description("Test Description : After successful login to application opens Dashboard page")
   @Story("Successful login of application opens Dashboard Page")

   public void DashboardTest() {

       objLogin = new LoginPage(driver);

       // Login to the application
       objLogin.login("Admin", "admin123");

       // Go to the dashboard page
       objDashboardPage = new DashboardPage(driver);

       // Verify the dashboard page
       objDashboardPage.verifyQuickLaunchOptions();

   }

   private class TestExecutionListener implements ITestNGListener {
   }
}

LoginTests

package AllureDemo.tests;

import AllureDemo.pages.DashboardPage;
import AllureDemo.pages.LoginPage;
import io.qameta.allure.*;
import org.testng.annotations.Listeners;
import org.testng.annotations.Test;

@Epic("Regression Tests")
@Feature("Login Tests")
@Epic("Web Application Regression Testing")
@Feature("Login Page Tests")
@Listeners(TestExecutionListener.class)
public class LoginTests extends BaseTest {

   LoginPage objLogin;
   DashboardPage objDashboardPage;

   @Severity(SeverityLevel.NORMAL)
   @Test(priority = 0, description = "Verify Login Page")
   @Description("Test Description : Verify the title of Login Page")
   @Story("Title of Login Page")
   public void verifyLoginPage() {

       // Create Login Page object
       objLogin = new LoginPage(driver);

       // Verify login page text
       objLogin.verifyPageTitle();
   }

   /* Failed Test */
   @Severity(SeverityLevel.BLOCKER)
   @Test(priority = 1, description = "Login with invalid username and password")
   @Description("Test Description : Login Test with invalid credentials")
   @Story("Unsuccessful Login to Application")
   public void invalidCredentialTest() {

       // Create Login Page object
       objLogin = new LoginPage(driver);
       objLogin.login("test", "test123");

       // Verify login page text
       objLogin.verifyErrorMessage();

   }
}

TestExecutionListener

package AllureDemo.tests;

import io.qameta.allure.Attachment;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;
import org.testng.ITestListener;
import org.testng.ITestResult;

public class TestExecutionListener implements ITestListener {

   @Attachment(value = "Screenshot of {0}", type = "image/png")
   public byte[] saveScreenshot(String name, WebDriver driver) {
       return (byte[]) ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);
   }

   @Override
   public void onTestFailure(ITestResult result) {
       saveScreenshot(result.getName(), BaseTest.driver);
   }

}

TestNG XML

Test Execution

In order to execute your tests, you have to open command prompt, go to the project directory, and write the below command.

allure serve allure-results

Allure in Cucumber BDD

You can also add Allure to your Cucumber BDD framework by adding the below dependency in the POM.xml file.

<!-- https://mvnrepository.com/artifact/io.qameta.allure/allure-cucumber-jvm -->
   <dependency>
       <groupId>io.qameta.allure</groupId>
       <artifactId>allure-cucumber6-jvm</artifactId>
       <version>2.14.0</version>
   </dependency>

</dependencies>

Add the following plugin to your Runner cukes file by referring to the below screenshot

"io.qameta.allure.cucumber6jvm.AllureCucumber6Jvm"

Sample Allure Report

Before we proceed to see the sample report in our Allure report tutorial, let’s first explore the 5 most important or commonly used annotations used in Allure. You can expand the capabilities of an Allure report by using more annotations, but these 5 will help you generate your basic first report.

• Allure Report Overview
• Categories in Allure Report
• Suites in Allure Report
• Graphs in Allure Report
• Behaviors in Allure Report
• Timeline in Allure Report
• Packages in Allure Report

Important Annotations used in the Allure report

• @Step – This annotation is used as a step definition to define any modifier with the parameter.
• @Epic – This annotation is used to define the large component or a whole product under which the Allure depends on.
• @Feature – We can use it to represent all the possible test coverage options based on the Test scenarios.
• @Stories – Every Epic has many stories and each of those stories represent a sub-product or sub-component.
• @Attachment – At the end of our test execution, we will have to add screenshots to our reports. And this annotation can be used to define the position of the screenshot.

Allure Report Overview

As you can see in the above screenshot, the Allure report overview has different sections such as suites, environment, categories, and so on. Let’s find out what they are in our Allure report tutorial.

Suites

A suite is a group of tests that share a common context such as a specific test environment or a particular test category. Suites are represented by colored blocks in the report’s timeline, and you can drill down into the details of each suite by clicking on them.

Environment:

The environment section contains information about the operating system, browser, framework, and version of the tools used.

Features By Stories:

In order to group test cases by features or user stories in an Allure report, you can use the @Feature or @Story annotations in your test code.

Categories:

Once this annotation is added to the test, the test cases will be grouped under the “smoke” and “regression” categories when your Allure report is generated. It is also possible to use the allure.category property to add the category information to the test case.

Executors:

Allure also supports custom executors that can be used when your current executors do not match the requirements of your project. Kindly note that they have to be implemented as a separate component.

Graphs:

Graphical representation of the status, severity, duration, and duration trend will also be available in an Allure report’s overview.

Timeline:

This section in an Allure report’s overview provides a graphical representation of the test execution. It will show the duration of each test case, and also specifies the order in which they were executed.

Categories in Allure Report

Next up in our Allure report tutorial, we’re going to explore the Categories tab that gives you the way to create custom defects classification for your test results.

By default, there will be two categories of defects in an Allure report:

• Product defects (Tests that failed due to an issue in the product)
• Test defects (Broken tests)

But you also have the option to create custom defect classifications such as skipped tests, outdated tests, and so on. You can do so by adding a categories.json file to the allure-results directory before report generation.

categories.json

[
  {
    "name": "Ignored tests", 
    "matchedStatuses": ["skipped"] 
  },
  {
    "name": "Infrastructure problems",
    "matchedStatuses": ["broken", "failed"],
    "messageRegex": ".*bye-bye.*" 
  },
  {
    "name": "Outdated tests",
    "matchedStatuses": ["broken"],
    "traceRegex": ".*FileNotFoundException.*" 
  },
  {
    "name": "Product defects",
    "matchedStatuses": ["failed"]
  },
  {
    "name": "Test defects",
    "matchedStatuses": ["broken"]
  }
]

(mandatory) category name

(optional) list of suitable test statuses. Default [“failed”, “broken”, “passed”, “skipped”, “unknown”]

(optional) regex pattern to check test error message. Default “.*”

(optional) regex pattern to check stack trace. Default “.*”

Test result falls into the category if their status is in the list and both the error message and stack trace match the pattern.

Suites in Allure Report

As you can see in the above screenshot, the Suites tab shows a standard structural representation of the executed tests, grouped by the suites and classes that can be found.

Graphs in Allure Report

Graphs allow you to see different statistics collected from the test data such as status breakdown, severity, and duration diagrams. They will be very effective in helping us understand the status of our test execution easily.

Behaviors in Allure Report

Behaviors group the test results according to Epic, Feature, and Story tags. It also consists of the status of each and every execution and has a detailed description as well.

Timeline in Allure Report

Allure adaptors will collect the accurate timings of the tests and arrange them in a sequential or parallel structure based on the timing. This visualization of the test execution will be available in the Timeline section of our Allure report.

Packages in Allure Report

The packages tab represents a tree-like layout of the test results, grouped by different packages as shown in the above image.

Advantages of Allure Report

In general, effective reporting can help shorten the development/QA lifecycle by providing both the developers and testers with all the information they will need. As seen above in our Allure report tutorial, it enables us to categorize the test failures into bugs, broken tests, and logs. Other vital information such as steps, fixtures, attachments, timings, history, and integrations with TMSs are also available to configure bug-tracking systems.

Managers and stakeholders will have a clear understanding of the project’s big picture, progress, timeline, defects clustering info, and so on. Now let’s take a look at the technical advantages that Allure reports have to offer.

• Allure is an open-source report engine built using AngularJS.
• It supports various frameworks such as JUnit, TestNG, Cucumber-Java, Selenide, Pytest, behav, Jasmine, Mocha, RSpec, Spock, PHPUnit, SpecFlow, NUnit, MSTest, etc.
• You can create visually rich reports that can be easily understood even by non-technical team members such as Stakeholders and Business Analysts.
• It has a command line interface to generate reports based on maven surefire plugins.
• It supports popular CI/CD platforms like Jenkins, TeamCity, Banboo, Gradle, Maven, and CodeFresh.
• Modularity and extensibility of Allure guarantee that you will always be able to fine-tune it to make Allure suit your needs better.

Note: Allure allows you to generate a single HTML file for easy sharing and viewing of test reports.

Why Use a Single HTML File?

• Simplified Sharing: No additional setup is needed to view the report.
• Compact and Portable: All required data is packaged into a single, standalone file.
• Browser Compatibility: Open and view in any modern browser without additional dependencies.

Steps to generate single Html file :

Open cmd for framework location
enter “allure generate –single–file D:\QA\QA-test-automation-codoid-Feb21\allure-results”

It will generate single html file in “allure-report” folder as below.

Conclusion

As a lightweight, flexible, multilingual test report tool, Allure Framework provides a neat web report that not only illustrates what has been tested in a concise manner. It also gives everyone involved in developing the maximum amount of useful information from testing every day. We hope that our Allure Report tutorial has given you a clear understanding of how to generate Allure reports for your project. As a leading automation testing company, we have also written a blog highlighting the key differences between Allure report and Extent report. So make sure to subscribe to our newsletter to not miss out on any of our latest blogs and updates.

gspread Python Tutorial for Google Sheets Automation

by Hannah Rivera | Feb 23, 2023 | Automation Testing, Blog | 1 comment

On average, more than 2 Billion people use Google Sheets on a monthly basis. It is a powerful tool for managing and analyzing data. It is a popular choice among individuals as it is very user-friendly in nature. Additionally, it is also widely used by professionals and businesses. With continuous & extensive usage, few tasks could end up becoming repetitive and time-consuming. But with the help of automation, you will be able to overcome this major issue and streamline your workflow and perform tasks more efficiently. Being an automation testing company, we have written this gspread Python tutorial to help you automate google sheets using Python. So let’s get started.

There are actually several libraries such as pygsheets, gdata, and gspread that one can use to automate Google Sheets using Python. And we have picked gspread for this particular tutorial. We’ll explore the basic setup & configuration required to get started, explore some common use cases, and then dive into how we can automate those use cases in Google Sheets using Python.

Google Sheet Automation Set up

Before we explore how to automate Google Sheets using Python in our gspread Python Tutorial, we’ll find out how to set up the prerequisites.

• Install a Python Library
• Create a New Project
• Enable API & Services
• Create Credentials
• Create a Google Sheet

Install a Python library

We have chosen gspread for this tutorial as it is one of the most popular and widely used libraries. So the first step in our gspread Python Tutorial is to install the gspread library that is needed to achieve Google Sheets automation using Python.

You can install gspread using the below command,

Command:

pip install gspread

Output:

Once you have installed the library, you’ll need to set up authentication. And to do that, you’ll have to create a “service account” in Google API Console and grant access to the Google Sheet you want to automate. Let’s see what steps have to be followed to do it.

Create a New Project

Navigate to Google Developers Console and click on ‘Create Project’.

For explanation purposes, we have created a project called ‘Gsheet Reader’ for our gspread Python Tutorial. You can also do it by filling in the required fields as shown in the below image and clicking the ‘Create’ button.

Enable API & Services

As the project has been created, you will see a new option to ‘Enable APIs and Services’ as shown below. You’ll have to click on it to add the Google Sheet API.

There will be a list of APIs and you can enter an appropriate keyword such as ‘sheet’ in the search bar and select the ‘Google Sheets API’.

You can then click the ‘Enable’ button from the Product Details page.

Create Credentials:

Google Sheets API will now appear in your Enabled APIs & Services tab. You will see 3 sections namely Metrics, Quotas, and Credentials under it. So the next step in our gspread Python Tutorial would be to see how to create the required credentials to access the Google Sheet API.

So click the ‘Create Credentials’ button and follow the below steps.

Credential Type

• Select ‘Google Sheets API’ in the ‘Select an API’ drop-down
• Select the ‘Application Data’ radio button, and
• Choose the ‘No, I’m not using them’ option in the last question.
• Click ‘NEXT’.

Service Account Details

After which, you’ll have to enter the Service account name & Service account ID in the respective fields and click the ‘CREATE AND CONTINUE’ button.

Grant Access

Now, you’ll have to specify the level of access you are going to provide for the service account.

Click on ‘Select a Role’ and select ‘Editor’ under the ‘Basic’ section. Based on your needs, you can choose whichever role will be the aptest.

Press ‘CONTINUE’ and leave the other optional fields and click DONE.

You will now be able to see the newly created Service account under the Credentials section.

Under the Keys Section, you can click on ‘ADD KEY’ and choose ‘Create new key’ to create a credential secret key.

There are two key types, and as suggested by Google, it is better to choose the JSON key type. After making the selection, click the ‘CREATE’ button.

Once you click the button, the key will be downloaded to your computer. Please make sure to not share this file with anyone else and keep it safe.

Tip: It will be helpful if you rename the file to credentials.json as it will be easy for you to remember the file name.

Create a Google Sheet

So the last step in our setup process is to create a Google Sheet that we can use to store our data. Once we are clear with that, we can go ahead and see the different Python code commands you can use to perform Google Sheet Automation.

If you already have a Google sheet, you can just copy the sheet url or sheet id as shown in the image as this copied string will be needed to access Google Sheets.

gspread Python Tutorial

Everything you’ll need to achieve Google Sheet Automation is now ready. So you can start automating the listed actions by typing the Python code commands we have mentioned in a code editor.

• Opening a Spreadsheet
• Get a Worksheet’s Name
• Read Data from a Sheet
• Insert Data into the Sheet
• Update Multiple Ranges

Opening a Spreadsheet

First up in our gspread Python Tutorial, we’ll be seeing how to open a spreadsheet using Python code commands. Remember the URL we had copied after creating a new Google Sheet? We will now use it to open that spreadsheet. You can also use your Sheet’s key to open the spreadsheet.

We will also have to use the JSON key we have created.

Code:

import gspread

Sheet_credential = gspread.service_account("credential.json")

# Open Spreadsheet by URL
# spreadsheet = Sheet_credential.open_by_url('paste your sheet url')

# Open Spreadsheet by key
spreadsheet = Sheet_credential.open_by_key('paste your sheet key')
print(spreadsheet.title)

Output:

You can see that the name of the Google Sheet we created (Gsheet Automation) has been fetched here.

Get a Worksheet’s Name

A Spreadsheet can have more than one worksheet and if you wish to print the name and ID of a worksheet, you can use the below Python code commands.

Code:

# to print worksheet name using sheet id
worksheet = spreadsheet.get_worksheet(0)

# to print worksheet name using sheet name
worksheet = spreadsheet.worksheet('Sample Sheet')
print(worksheet)

Output:

Read Data from a Sheet

Next up in our gspread Python tutorial, we’re going to see the command you’ll have to use to read data from a Google Sheet. In this example, we will be reading all the values present in a specific worksheet and printing it.

Code:

# To read all values from the sheet
all_values = worksheet.get_all_records()
for value in all_values:
    print(value)

Output:

Insert Data into the Sheet

Reading the data alone isn’t enough. You’ll have to insert data into a sheet as well. So, let’s look at the Python Code command you’ll have to use to achieve that. In our example, we will be updating multiple values after a defined row and read & print the updated values.

Code:

# Update multiple values after A6 row
worksheet.update('A7', [["106", "Robert","J","Pass" ], ["107", "Robert","G","Fail"]])

# read data after update
update_data = worksheet.get_all_values()
for valu in update_data:
    print(valu)

Output:

Update Multiple Ranges

Finally in our gspread Python tutorial, we are going to see the commands you can use to update multiple ranges of data at the same time.

Code:

# Update multiple ranges at once
worksheet.batch_update([{
    'range': 'E1:F2',
    'values': [['Name', 'Age'], ['Mohammed', '24']],
}, {
    'range': 'G1:H2',
    'values': [['A', 'AB'], ['C', 'CD']],
}])
# To Read data after the update
update_data = worksheet.get_all_values()
for valu in update_data:
    print(valu)

Output:

CONCLUSION

So in our gspread Python tutorial, we have laid the foundations you’ll have to know to achieve Google Sheets automation using Python. By following these simple steps, you can easily automate tasks such as data entry, data analysis, and report generation. We hope this will help you significantly improve your workflow and save you time. Being a leading big data analytics testing company, we have used Python libraries and found gspread to be the best of the lot. Hope you find it useful too.

Allure report vs Extent report. Which is Better?

by Charlotte Johnson | Jan 31, 2023 | Automation Testing, Blog | 1 comment

In today’s testing world, almost everything is pre-defined and automated to minimize the requirement of humans at different levels. As automation testing helps us significantly reduce the time and effort required to perform the tests, we will be able to test more. But it isn’t just about running automated tests day in and day out. You’ll have to validate if the completed automation tests covered the requirements, if there were any false positives, and so much more. And that’s where the use of effective reporting tools comes into the picture! So in this blog, we will be comparing Allure Report vs. Extent Report to help you choose the right one for your testing needs. However, Extent Report is going to be deprecated very soon, and a modern replacement for it is ChainTest Report.

We have used both Allure and Extent reports while delivering our automated testing services to our clients and have written this blog based on real-world experience. But before we get started with our Allure Report vs Extent Report Comparison, let’s take a quick look at the importance of Reporting.

The Importance of Reporting

A report is otherwise said to be the evidence for the testing you have done. They also help you analyze the overview of your test run with information such as the test summary, errors, and reason for failure. So by logging & maintaining the reports, you’ll be able to identify the root cause of a bug or an issue when it is found. You will also be able to identify any particular pattern to predict the location of other bugs.

Since most reports will be seen by stakeholders, you’ll have to make sure that your reports can be understood by people who don’t have the technical expertise as well.

Allure Report vs Extent Report: Key Differences

Allure Report vs Extent Report: Full Comparison

A comparison table makes it very easy to get an idea of the core differences between Allure & Extent reports. But you will not be able to understand each point completely. So we will now be elaborating on the points we saw in our Allure Report vs Extent Report table. Let’s start with Allure.

Allure Report:

Allure Report is an automation test reporting tool that can be used to assess or validate the automated test execution.

Feature Rich:

As stated in our table, Allure reports have a lot of handy features that we can use. But on the contrary, Extent report only has a general dashboard and the status & category sections.

Categories & Suites

All the tests will be delivered based on the categories we defined. And the test results will be projected in terms of the Suites we classify.

Timeline feature:

It will record the total time it takes to complete the run. And, it will note the time taken by each scenario as well. So you can compare each and every test’s time frame and get an accurate timeline of how long it takes to run your tests.

Behavior feature:

It groups your tests based on the epic, group, and story you tag your tests with. This will make it extremely easy for you to generate a highly customized report.

JIRA Integration:

If you use JIRA in your project, Allure reports are definitely better than Extent Reports as you can integrate Allure reports with JIRA. Whereas, Extent reports cannot be integrated with JIRA as stated in our Allure report vs Extent report table.

Visual Reports:

The main advantage of using this tool is that the generated reports will be visually appealing with graphical charts. Graphs will help the viewer understand the result in an easily comprehensible way by using Bar Charts or Pie Charts.

So even non-technical people involved in the software development process such as Stakeholders and Business Analysts will understand it with ease.

Though Extent report also makes use of Pie charts, Allure report is far more advanced as we can see in our sample report.

Getting Started with Allure Report

We can add the Allure report to our Maven project by adding the following dependency:

<plugin>
 <groupId>io.qameta.allure</groupId>
 <artifactId>allure-maven</artifactId>
 <version>2.10.0</version>
</plugin>

Important Annotations used in Allure report

@Step – It is used as a step definition to define any modifier with the parameter.

@Epic – It is used to define the large component or a whole product under which Allure depends on.

@Feature – It can be used to represent all the possible test coverages based on the Test scenarios.

@Stories – Every Epic will have many stories and each story represents a sub-product or sub-component.

@Attachment – We will definitely need the screenshots from the test execution in our reports. So we can use this annotation to determine where the screenshot will be placed.

Extent Report

Similar to Allure, Extent report is also an open-source automation test reporting library and can be used with popular automation frameworks such as JUnit, NUnit, Cucumber TestNG, and so on.

Extent Report is good at giving the best report based on the test we run with the preconditions and postconditions we give.

Summarized Reports

Normally, Extent report will summarize the overall automation runs you have made and give you a nice overview of the result. It also gives you information like the number of test cases executed, the passed count, and the failure count.

The passed Scenarios will be seen in Green and the failed scenarios will be seen in Red. So you will be able to quickly filter out the failed tests or passed tests from all the tests based on whatever your need is.

You can also see the categories based on the tags you run the features. You can also see all the reports under the selected category. Additionally, it also gives you the time taken for each test suite as well as individual scenarios to be executed. So, we can even track the estimated time of every run.

So one can say that Extent is on par with Allure in this particular use case.

Easy to View:

If your testing needs require you to have the report in pdf format, Extent Report would be the way to go. As seen in the Allure report vs Extent Report comparison table, Allure reports cannot be generated as pdf files. It is also far easier to view Extent reports as you will not need any command line.

Getting Started with Extent Report:

You can generate the extent report in the path that you specify in the syntax as shown below.

ExtentReports reports = new ExtentReports("Path where you want to store the report", true/false);

ExtentTest test = reports.startTest("Name of the Test you wish to run");

The boolean condition here is used to indicate whether you want to overwrite the existing report or want to create a new one every time it runs.

By default, it will consider this option to be “True” and overwrite the existing report every time the test runs.

Important Keywords used in Extent Report

The use of the ExtentTest is that it will add the test steps and logs that have to be added to the previously generated HTML report. It uses some of the keywords such as startTest, endTest, log, and flush for this purpose.

startTest – When you have to add a precondition before the step

endTest – To add any postconditions before the step

Log – To know the status of the steps

Flush – When you have to delete the existing data in the report and generate a new report.

Allure Report vs Extent Report: Final Verdict

Now that we’ve come to the conclusion of our blog, it’s time to give a final verdict. It is usually never a this or that type of an answer as making a decision is purely dependent on the needs of your project. But with that being said, Allure report would be the better choice for most use cases. That is why we have mentioned the individual advantages of both the Allure and Extent to help you make an educated decision. We hope you enjoyed reading our Allure Report vs Extent Report blog. And if you did, make sure to subscribe to our newsletter to never miss out on any of our latest updates.

Frequently Asked Questions

Cypress Limitations you should be aware of

by Chris Adams | Jan 12, 2023 | Automation Testing, Blog | 0 comments

Cypress is a great automation testing tool that has been gaining popularity in recent times. One of the key features of Cypress is that it operates in the same context as the application under test. This allows it to directly manipulate the application and provide immediate feedback when a test fails, making it easier to debug and troubleshoot issues in tests. But the fact of the matter is that no tool is perfect. Being a leading automation testing company, we have used Cypress in many of our projects. And based on our real-world usage, we have written this blog covering the various Cypress limitations that will be beneficial to know about if you have decided to use the tool. So let’s get started.

List of Cypress Limitations

• Language Support
• Testing Limitations
• Browser Support
• Complexity
• Multi-Origin Testing
• XPath Support
• iFrame Support

Language Support

Let’s start off our list of Cypress limitations with the number of languages it supports as it is an important factor when you choose a framework. As Cypress is a JavaScript-based testing framework, it is primarily intended to be used with JavaScript and its related technologies.

It does support TypeScript as it is a typed superset of JavaScript. But there is a catch, as you’ll have to transpile your TypeScript code to JavaScript using a build tool like Webpack or Rollup.

Likewise, you can follow the same process to use Cypress with languages like CoffeeScript or ClojureScript by transpiling the code to JavaScript.

Though it seems like a workaround, it is important to note that Cypress wasn’t designed to work with such transpiled code. So you may encounter issues or limitations when using it with other languages other than pure JavaScript. If you do opt to use any other language apart from JavaScript, make sure to thoroughly test if it is fully compatible with the framework.

Testing Limitations

The second major Cypress limitation is the lack of testing capabilities for mobile and desktop applications. As of now, Cypress can be used to test web applications only.

Even in Selenium, you will be able to perform mobile app testing using Appium server. But when it comes to Cypress, you have no such provision to perform mobile app testing.

Browser Support

The next Cypress limitation is the lack of support for browsers such as Safari and Internet Explorer. Though Internet Explorer has been retired by Microsoft, certain legacy applications might still depend on Internet Explorer.

Cypress works with the latest versions of Chrome and Electron. But when it comes to other popular browsers such as Firefox and Microsoft Edge, you’d have to install additional browser extensions. Due to this, these browsers may not exhibit the same level of support as Chrome and Electron. So a few features may not work as expected.

It is also recommended you use the latest version of Chrome or Electron when running your Cypress tests. But if you wish to use an older version of these browsers, these are the supported browsers as of writing this blog.

• Chrome 64 and above.
• Edge 79 and above.
• Firefox 86 and above.

Complexity

Complexity is the next Cypress limitation on our list as it can use only node.js, which is complex and knowledge-demanding. Though typical JavaScript is Synchronous, we’ll have to use asynchronous JS in Cypress. In addition to that, other advanced JavaScript methodologies such as promises and jQuery should also be known.

So if you are starting to learn automation or if you have been using other languages such as Java or Python for your automation, you’ll have a tough time using Cypress.

Multi-Origin Testing

The next Cypress limitation is that performing multi-origin testing is not as easy as it can be done using Selenium. If your automation testing doesn’t involve switching from one domain to another or if it has a different port, problems will arise.

Though the issue was partially addressed with version 12.0.0, you’ll still have to use the cy.origin() command to specify the domain change during such scenarios. Whereas, Selenium doesn’t have any such limitation when it comes to changing the origin domain during the tests.

Similar to this partial workaround, the next two Cypress limitations we are about to see can also be partially overcome with the help of Cypress plugins. We have also written a blog featuring the best Cypress plugins that will make testing easier for you. So make sure to check it out.

XPath Support

XPath is a crucial aspect of automation testing as it is one of the key object locators. But unfortunately, Cypress does not support XPath by default. However, this Cypress limitation is at the tail-end of our list as you can use the cy.xpath() command to evaluate an XPath expression and retrieve the matching elements in the DOM. This command is provided by the cypress-xpath plugin that you’d have to install separately.

iFrame Support

By default Cypress does not support iframes. However, you can use the cy.iframe() command to evaluate iframe actions and retrieve the matching elements in the DOM. But this command can be used only if you have installed the cypress-iframe plugin.

Conclusion

As we had mentioned at the beginning of the blog, no tool is perfect and each would have its own fair share of limitations. Likewise, these are the major Cypress limitations encountered by our dedicated R&D team. Nevertheless, we were still able to use Cypress and reap all the benefits of the tool to deliver effective automation testing services to our clients as these limitations didn’t impact the project needs.

So if these limitations are not huge concerns for your testing needs, you can use Cypress with confidence. If these are actual concerns, it is better you look into the alternatives.