Blog

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.

Best Cypress Plugins Every Tester Must Know

by Mollie Brown | Jan 9, 2023 | Automation Testing, Blog | 0 comments

A Cypress plugin is a JavaScript module that extends the functionality of the Cypress test runner. They have the ability to create new commands, modify existing commands, and register custom task runners. So knowing the best Cypress plugins can be very useful as you will be able to save a lot of time and streamline your automation testing. Being a leading automation testing company, we have listed out the Best Cypress Plugins we have used in our projects. We have also explained the functionality of these plugins and have mentioned how you can install them as well.

It is important to note that Cypress plugins can be created by anyone. So you can also create a plugin if different projects share a common functionality or utility function that can use one.

But the great advantage here is that Cypress already has a wide range of community-created plugins that cover most of the required functionality such as using XPath, creating HTML reports, and so on.

But before we take a look at the best Cypress plugins and their functionalities, we’ll have to know how to install them.

Installing a Cypress Plugin

Once you have identified a Cypress plugin you wish to use, there are a few standard steps you’ll have to follow to add it to your project. Let’s find out what they are.

But there will be exceptions in a few cases and you’ll need to do a few extra steps to use the plugin. We will explore those exceptions when we look into the best Cypress plugins in detail.

1. Add it as a dependency to your project by using this command

npm install --save-dev @name_of_the_plugin

2. Register the plugin in your Cypress configuration file (cypress.config.js)

Add the object into the “plugins” array as shown in the below example

{
  "name": "@name_of_the_plugin"
}

Now that we are aware of the prerequisites you’ll need to know, let’s head directly to our list of the Best Cypress Plugins and find out what makes them so great.

Best Cypress Plugins

• @badeball/cypress-cucumber-preprocessor
• @bahmutov/cypress-esbuild-preprocessor
• @badeball/cypress-cucumber-preprocessor/esbuild
• @cypress/xpath
• Cypress-iframe
• Cy-verify-downloads
• Multiple-cucumber-html-reporter
• cypress-file-upload

@badeball/cypress-cucumber-preprocessor

It is a customized version of the cypress-cucumber-preprocessor plugin that you can use to write Cypress tests in the Gherkin format.

The advantage here is that Gherkin uses natural language statements that make the automation tests very easy to read and understand. Apart from technical people being able to understand the tests, people with no technical knowledge also will be able to understand them. Since that is an important aspect of automation testing, we have added this plugin to our list of the best Cypress plugins.

Once you have installed and registered the plugin using the above-mentioned instructions, you will be able to write your tests using the Gherkin syntax and save them with the .feature file extension. These files will be parsed and converted into executables by the plugin.

@bahmutov/cypress-esbuild-preprocessor

It is a plugin that uses esbuild, a JavaScript bundler to preprocess your test files before they are run by Cypress.

If you are using JavaScript features such as JSX or TypeScript in your tests, this plugin would be useful as esbuild will convert these features to plain JavaScript that can be run in older browsers too.

@badeball/cypress-cucumber-preprocessor/esbuild

The @badeball/cypress-cucumber-preprocessor/esbuild plugin is a custom version of one of the best Cypress plugins we have seen already. As the name suggests, it is a modified version of the cypress-cucumber-preprocessor plugin.

The @badeball/cypress-cucumber-preprocessor/esbuild plugin extends the functionality of writing tests using the Gherkin language by using esbuild. You will be able to transpile your test files using esbuild and parse them using Cucumber before they are run by Cypress.

This can be very useful if you are using modern JavaScript features such as JSX or TypeScript in your tests.

@cypress/xpath

Using an XPath to locate elements for your automation tests is a very common practice in automation testing. And you can make use of the @cypress/xpath plugin to add support for using XPath expressions in your tests.

It can be particularly useful when you have to target elements that don’t have unique ID attributes, or if you want to locate elements based on their exact position or relative position with respect to other elements.

You can target elements in your tests by using the cy.xpath() command.

Cypress-iframe

iframes are HTML elements that allow you to embed another HTML document within the current page. They are used in numerous websites as they can be useful for displaying content from external sources or for separating different sections of a page.

If the site you are testing does have an iframe, you’ll have to know how to interact with it in your automation tests. So you can make use of the cypress-iframe plugin to shift the focus of your tests to an iframe element.

Cy-verify-downloads

As the name suggests, this Cypress plugin can be used to validate if a file has been downloaded during your automation testing. It is common for applications to offer file downloads to their users and that is why this plugin has found its spot in our list of best Cypress plugins.

It basically uses two arguments to fulfill its purpose, and they are the file path and the expected content of the download file. So you can use cy.verifyDownload() command to ensure that your application is generating and serving the correct files to users.

Multiple-cucumber-html-reporter

Reporting is a very important part of automation testing and we have chosen a plugin that will help you generate HTML reports for your tests. The Multiple-cucumber-html-reporter is a plugin for the Cucumber test framework that generates an HTML report for your tests.

Cucumber is a tool that allows you to write tests using natural language statements (written in the Gherkin syntax), and the Multiple-cucumber-html-reporter plugin allows you to generate an HTML report that shows the results of these tests.

Of our list of the best Cypress plugins, this is the only plugin that has an exception when it comes to using it after installation and registration. You’ll have to configure the plugin to generate the report in the format you want.

As usual, you can use the below command to install the plugin as a dependency on your project.

npm install --save-dev multiple-cucumber-html-reporter

After which, you’ll have to configure the plugin by creating a JavaScript file that requires the plugin. You can configure the JavaScript file with the appropriate conditions based on which your HTML report will be generated. Let’s take a look at an example to help you understand it clearly.

Example:

Let’s generate an HTML report based on the JSON files in the “path/to/json/files” directory and save it to the “path/to/report/directory” directory. We will be including metadata about the browser & platform used to run the tests and a few custom data such as the title and additional details about the project and release.

const reporter = require("multiple-cucumber-html-reporter");
 
reporter.generate({
  jsonDir: "path/to/json/files",
  reportPath: "path/to/report/directory",
  metadata: {
    browser: {
      name: "chrome",
      version: "78.0"
    },
    device: "Desktop",
    platform: {
      name: "Windows",
      version: "10"
    }
  },
  customData: {
    title: "My Report",
    data: [
      { label: "Project", value: "My Project" },
      { label: "Release", value: "1.0.0" },
      { label: "Execution Date", value: "January 1, 2020" }
    ]
  }
});

cypress-file-upload

Similar to applications having the provision to download files, the ability to upload files from the local system to the server is also a common function. So you can make use of this plugin to test if your application uploads a file as expected.

cy.upload_file is the command you’ll have to use to get this functionality.

Conclusion

As mentioned earlier, there are so many great Cypress plugins and we found these to be the most important ones that every automation tester must know. We hope you are now clear about how to install, register, and use all of the best Cypress plugins we’ve gone through in our blog. Even if you wish to use any other Cypress plugin, you can make use of the standard installation and registration process to get started with it. Being an experienced automated testing as a service provider, we have published numerous informative blogs about Cypress and will be publishing more. So make sure to subscribe to our newsletter to ensure you do not miss out on any of our latest posts.

Pytest BDD vs Behave: Pick the Best Python BDD Framework

by Arthur Williams | Dec 30, 2022 | Automation Testing, Blog | 0 comments

Similar to all popular programming languages, Python also has numerous BDD frameworks that we can choose from. Out of the lot, Pytest BDD and Behave are the most widely used BDD frameworks. Being a leading automation testing company, we have used both Pytest BDD and Behave in our automation testing projects based on business needs. We believe it is crucial for every tester to know how to implement a readable and business-friendly automation testing solution. So in this blog, we will be pitting Pytest BDD vs Behave to help you choose the right framework for your automation testing needs by comparing the two based on our real-world usage.

For those who are unfamiliar or new to Python and BDD, let’s have a small introduction for both before we start our Pytest BDD vs Behave comparison. If you are already familiar with them, feel free to head straight to the comparison.

BDD

Behavior-Driven Development (or BDD) is an agile software development technique that promotes collaboration not only between developers and testers; but also with non-technical or business stakeholders in a software project. BDD achieves this by following a simple Given, When, and Then format (Gherkin) to write test cases that anybody can understand. Before we head to the Pytest BDD vs Behave comparison, let’s take a look at the list of popular Python BDD frameworks available.

List of Python BDD Frameworks

1. Behave

2. Pytest BDD

3. radish

4. lettuce

5. freshen

Though there are even more Python BDD frameworks, these are the most well-known and widely used options. But it is important to note that not every BDD framework is for everyone. That is why we have picked out Pytest BDD and Behave for our comparison.

Python Behave

If you have prior experience in using a Cucumber BDD framework, you would find Behave to be similar in many ways. But even if you are starting afresh, Behave is quite easy to get started with. The primary reason for that is Behave’s great online documentation and the availability of easy tutorials. We will be covering a direct Pytest BDD vs Behave comparison once we explore the individual pros and cons of both these frameworks.

Pros

• Simple Setup: No need for explicit scenario declarations.
• Dynamic Arguments from Command Line: Allows passing custom arguments dynamically, making test execution more flexible.
• Better Feature File Organization: Feature files are automatically detected without extra setup.
• Scenario Outlines & Backgrounds: Helps in reusing test steps and making tests more maintainable.
• BehaveX for Parallel Execution: Although Behave doesn’t natively support parallel execution, BehaveX helps achieve this.

Cons

• No Built-in Parallel Execution: Unlike Pytest BDD, Behave requires additional tools for parallel test execution.
• Limited IDE Support: Fully supported only in PyCharm Professional.
• Limited Reporting: Supports Allure, JSON, and JUnit reports, but lacks HTML reports.

Pytest BDD

Pytest BDD implements a subset of the Gherkin language to enable project requirements testing and behavioural-driven development. Pytest fixtures written for unit tests can be reused for feature step setup and actions with dependency injection. This enables true BDD with just the right amount of requirement specifications without having to maintain any context object containing the side effects of Gherkin imperative declarations.

Let’s view the listed pros & cons of Pytest and then proceed to the tabular column where we compare Pytest BDD vs Behave.

Pros

• Fixture Support: Reuse Pytest fixtures for setup and teardown, reducing redundant code.
• Seamless Integration: Works flawlessly with Pytest and major Pytest plugins like pytest-catchlog (for logging) and pytest-vscodedebug (for debugging), making troubleshooting much easier.
• Rich Plugin Ecosystem: Pytest supports 800+ external plugins, offering great flexibility.
• Parallel Test Execution: Pytest BDD allows running tests in parallel, which significantly reduces test execution time.
• Supports Multiple Report Types: Generate HTML reports, Allure reports, and JUnit reports.

Cons

• Feature File Declaration: You need to explicitly declare feature files in step definition modules using @scenario or scenarios().
• Scenario Outline Parsing: Requires additional parsing steps for scenario outlines.
• Limited Community Support: Compared to Behave, fewer people use Pytest BDD, meaning finding solutions for niche issues can be more challenging.

Pytest BDD vs Behave: Key Differences

Pytest BDD vs Behave: Best Use Cases

Pytest BDD

Parallel Execution – Behave has no in-built features that made it possible to run the tests in parallel. Likewise, the once popular framework behave-parallel, which made it easier to run tests in parallel on Python behave, has been retired. So if parallel test execution is an important factor, Pytest will definitely be the better choice.

Pytest BDD allows for the unification of unit and functional tests. It also reduces the burden of continuous integration server configuration and the reuse of test setups.

HTML Reports – Behave doesn’t support HTML reports, and if that is one of your requirements, then you’ll have to pick Pytest BDD. Pytest BDD also has support for Allure reports which is also another widely used type.

Behave

Ease of Use – As seen in the Pytest BDD vs Behave comparison table, the step definition naming is much easier in Behave as Pytest requires a defined prefix or suffix. As additional code is required for declaring scenarios, implementing scenario outlines, and sharing steps in Pytest BDD, Behave in general is easier to use. It is also easier to setup as it has an inbuilt test runner.

The terminal log will be more elaborate in Behave when compared to Pytest. The reason for that is Behave runs the test with feature files that are written in the Given When & Then format. So you can easily identify where the error is.

Conclusion

So it is evident that both Pytest BDD and Behave have their own pros and cons. So based on your automation testing needs, you can use our Pytest BDD vs Behave comparison table and recommendations to make a well-educated decision. Being a test automation service provider, we have predominantly used Pytest BDD in many of our projects. If you could work around Pytest BDD’s complexity, it is a great option. If not, Behave could be a great alternative that you can choose.

Frequently Asked Questions

Page Object Model in Cypress Tutorial with Example

by Anika Chakraborty | Dec 20, 2022 | Automation Testing, Blog | 0 comments

Designing an effective test automation framework is an integral part of automation testing. It is important that your test automation framework has no code duplication, great readability, and is easy to maintain. There are many design patterns that you can use to achieve these goals, but in our experience, we have always found Page Object Model to be the best and would recommend you follow the same. As Cypress has been gaining a lot of popularity over the years, we will be looking at how you can implement Page Object Model in Cypress. To help you understand easily, we have even used a Cypress Page Object Model example. So let’s get started.

In a Page Object Model, the page objects are always separated from the automation test scripts. Since Cypress has the ability to enable Page Object Model, the page files in POM are separated into different page objects and the test cases are written in test scripts.

How to Implement the Page Object Model in Cypress?

Being an experienced automation testing company, we have implemented Page Object Model in Cypress for various projects. Based on that experience, we have created a Cypress Page Object Model example that will make it easy for you to understand.

• Create a Pages Folder
• Add Methods & Locators
• Create a Step Definition Folder
• Import & Execute

Let’s assume that we have to automate the login process in a sample page and that we have two pages (Home Page & Login Page) to focus on.

Create a Pages Folder

The project structure is an aspect we’ll need to know for implementing Page Object Model in Cypress. So we have created a separate folder called pages under the Cypress folder to store both the Home and Login pages.

In the example above, we can see both the CodoidPortalHomePage.js and CodoidPortalLoginPage.js. Under the ‘pages’ folder we created.

Add Methods & Locators

Now that we have created separate pages, we have added all the required methods related to Codoid’s home page to CodoidPortalhomePage.js and the ones related to Codoid’s login page to CodoidPortalLoginPage.js.

To increase the reusability, we have added the locators as variables in both instances.

Home Page

export class CodoidPortalHomePage{
 
    txtBox_Search = ':nth-child(2) > .oxd-input-group > :nth-child(2) > .oxd-input'
    codoidLogo = ':nth-child(3) > .oxd-input-group > :nth-child(2) > .oxd-input'
    btnSearchIcon = '.oxd-button'
 
    enterSearchKeyword(Username){
        cy.get(this.txtBox_Search).type(Username)
    }
 
    verifyCodoidLogo(Password){
        cy.contains(this.codoidLogo)
    }
 
    clickSearchIcon(){
        cy.get(this.btnSearchIcon).click()
    }
}

Login Page

export class CodoidPortalLoginPage{
    txtBox_UserName = ':nth-child(2) > .oxd-input-group > :nth-child(2) > .oxd-input'
    txtBox_Passwords = ':nth-child(3) > .oxd-input-group > :nth-child(2) > .oxd-input'
    btnLogin = '.oxd-button'
    txtDashBoardInHomePage = '.oxd-topbar-header-breadcrumb > .oxd-text'
    txtInvalidcredentials = 'Invalid credentials'
    subTabAdmin = 'Admin'
    txtSystemUserInAdminTab = 'System Users'
    enterUserName(Username){
        cy.get(this.txtBox_UserName).type(Username)
    }
    enterPassword(Password){
        cy.get(this.txtBox_Passwords).type(Password)
    }
    clickLoginBtn(){
        cy.get(this.btnLogin).click()
    }
    verifyHomePage(){
        cy.get(this.txtDashBoardInHomePage)  
     }
     verifyAdminSection(){
        cy.contains(this.subTabAdmin).click()
     }
     verifySystemUser(){
        cy.contains(this.txtSystemUserInAdminTab)
     }
}

Create a Step Definition Folder

The next step in implementing Page Object Model in Cypress would be to create a ‘Step Definition folder. We have created it under the ‘e2e’ folder, which stores all the test cases. We have then created a test spec file by the name ‘testFile.js’ under the ‘step definitions’ folder.

Note: If you are using a Cypress version that is below 10, you’ll have to create a ‘step definitions’ folder under ‘integration’ and not under e2e.

Import & Execute

The final step in implementing the Page Object Model in Cypress would be to import the pages we have created to access its methods and execute them. So we will be creating instances of the CodoidPortalHomePage.js and CodoidPortalLoginPage.js classes and call the respective methods as shown in the code snippet below.

import {
    Given,
    When,
    Then,
  } from "@badeball/cypress-cucumber-preprocessor";

import { HomePage } from "../../pages/CodoidPortalHomePage";
import { LoginPage } from "../../pages/CodoidPortalLoginPage";

const homeage = new CodoidPortalHomePage()
const loginPage = new CodoidPortalLoginPage()


Given('User is at the login page', () => {
    cy.visit('https://opensource-demo.orangehrmlive.com/')
})

When('User enters username as {string} and password as {string}', (username, password) => {
    loginPage.enterUserName('Admin')
    loginPage.enterPassword('admin123')
})

When('User clicks on login button', () => {
    loginPage.clickLoginBtn()
})

Then('User is able to successfully login to the Website', () => {
    homeage.verifyHomePage()
})

Now that we have implemented Page object model in Cypress, it’s time to execute the test file in Cypress. So you can open Cypress by running the following command in the terminal.

npx cypress open

Once you have opened Cypress, all you have to do is run the testfile.spec.js file.

Best Practices for Page Object Model in Cypress

Assertions should not be included in page objects

When building end-to-end test scripts, aim to include only one main assertion or a set of assertions per script. Additionally, you should not place assertions in any of the functions provided by your page objects.

Identify the page object class by using a clear name

It’s important to make sure the name you choose makes it 100% clear what’s inside the page object. If there is a scenario where you are unable to pinpoint what the page object does, then it is a sign that the page object does too much. So make sure to keep your page objects focused on particular functions.

Methods in the page class should interact with the HTML pages or components

Make sure your page class has only the methods that an end user can use to interact with the web application.

Use Locators as variables

There are high chances for the “Xpath” of an element changes in the future. So if you use a locator as a variable, you can just change the Xpath of the single file, and it will be applied to all the other files that call the same “Xpath”.

Separate the Verification Steps

Ensure to separate the UI operations and flow from the verification steps to make your code clean and easy to understand.

Conclusion:

So in addition to using a Cypress Page Object Model example, we have also listed the best practices that you can use to implement the same in your project. Implementing Page Object Model in Cypress will make it very easy when you have to scale your project and make maintaining it seamless as well. Being a leading automation testing service provider, we will be publishing such insightful blogs regularly. So make sure you subscribe to our newsletter to never miss out.