DEV Community: BhasinAnshita

Introduction to Shift Left Testing

BhasinAnshita — Mon, 10 Jul 2023 13:26:17 +0000

Shift-left testing is a software testing approach where testing is moved to an earlier phase in the development process, closer to the development phase. The goal of shift-left testing is to catch and fix defects as early as possible in the development cycle, which can save time and resources in the long run.

A real-time example of shift-left testing is in a microservices architecture where each service is developed and tested independently before being integrated with other services.

For example, My team is developing a payment page for an airline platform that involves new microservice for managing shopping cart and order service. The development team begins by writing unit tests for the cart and order service, which test the individual functions and methods of the service.

Once these tests pass, the team can proceed to integration testing, where the both services (cart and order) are tested against other services in the platform to ensure that it works as expected.

Once the development and testing of the both services (cart and order) is completed, it is then deployed to a staging environment where it is tested again. If there are any issues found in staging, they are resolved and the service is deployed to production.

By performing testing early in the development process, the team can catch and fix defects early on, saving time and resources that would have been spent on later stages of testing.

It’s also important to note that shift-left testing is not only about testing earlier but also about involving the whole team in the testing process, where developers, QA, and ops collaborate to test, identify and fix issues, which leads to a more streamlined and efficient development process.

Get started with this complete Selenium automation testing tutorial. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing.

Adopting Shift left testing in a software development lifecycle

The software development life cycle (SDLC) is a process followed in an organization for a software project. It consists of various stages starting from planning, designing, developing, testing, deploying, and maintaining software. It is a framework that outlines the steps and activities involved in developing software, from the initial planning stages to the final deployment and maintenance of the software.

Adopting Shift left testing in a software development lifecycle improves the quality of the software and reduces the time and cost required to fix defects later in the process.

Below are some ways in which you can adopt to shift left testing in your organization:

1.Involve testers earlier in the development process:

Testers should be involved in the development process as early as possible, to provide feedback and help identify defects. This involves working closely with developers, attending daily stand-ups, and participating in design and code reviews.

To implement shift left testing, organizations often follow Agile Methodology and have sprint ceremonies such as sprint grooming and sprint planning where both QA and Development teams are involved from the beginning.

During this time, QA can ask clarifying questions about requirements and provide inputs as well.

2.Implement BDD/TDD Approach:

This approach has several benefits. The test cases prepared by QA can help developers think about scenarios they may not have considered. Additionally, QA may identify cases that were missed by the product owner, business analyst, or the person who is responsible for gathering requirements.

Identifying potential issues and creating test cases early in the development process can save time and effort later on. Without this early identification, issues may not be discovered until later stages of development or testing, at which point it may be more time-consuming and costly to make changes to address them.

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to automation testing Python to help you streamline your testing process.

3.Encourage developers to write unit testing:

Unit testing involves testing individual units or components of code to ensure that they are working correctly. It is an important shift left testing technique that can be used to identify and fix defects early in the development process. You can provide training on how to write effective unit tests, as well as tools and frameworks that can be used to automate unit testing.

4.Conducting Internal Demo:

Conducting an internal demo to the sprint team on the sprint closure day is an effective way to implement shift left testing. During this demo, team members can visually see the work completed in the previous sprint, including any changes or updates to the website or product.

This allows them to provide feedback and identify potential issues early on, rather than waiting for formal testing to be conducted later in the process.

By involving the entire team in the demo, you can increase the chances of identifying potential issues and gathering valuable feedback. This can help improve the quality and value of the product, as it will not only be tested by a dedicated tester at a later stage but also reviewed and assessed by the entire team. This task ensures all relevant scenarios are considered and necessary changes are made before the product is released.

In this Flutter testing tutorial, we will discuss how to test flutter apps manually and automation on real device cloud.

5.Monitor test coverage:

Use tools to monitor test coverage or the percentage of code that is tested, to ensure that you are testing all relevant code. Using code coverage tools can help you in monitor test coverage and also helps in analysing your codebase and reports on the percentage of code that is covered by tests.

6.Use version control and code review:

Use version control systems, such as Git, to track changes to your codebase and enable collaboration. Use code review to ensure that code is reviewed and tested by multiple team members before it is deployed.

For example, you might set up a code review process in which all new code is reviewed by at least one other team member before it is merged into the main codebase.

This can help identify and fix defects early on and improve the overall quality of your software. By incorporating these techniques into your shift left testing strategy, you can effectively identify and fix defects early in the development process, improving the quality and efficiency of your software

7.Automation Testing:

Automated testing can be used to test individual units or components of code as they are being developed, allowing you to identify defects early on. This can help reduce the time and effort required for testing later on and improve the quality of your software by identifying and fixing defects early in the development cycle.

For example, when developing microservices, you can use automated testing to perform component testing early in the development process. By preparing test cases based on the Swagger or Confluence page and calling the service directly from the feature branch, you can verify that the service is working as intended.

You can also write code in the same branch as the development team and check classes or enumerations that are being used to ensure that they meet the requirements.

By performing early testing, you can identify bugs and defects at an early stage of software development, improving the quality and efficiency of your development process.

In this Selenium with Java tutorial, you will learn everything you need to know to kick start your journey in Selenium automation testing with Java.

8.Testing every component:

Testing every component is an important aspect of shift left testing. If you are testing an API and not all of the API is developed, you can still test what is available and mock the response for the rest.

Using concepts such as stubs and drivers, you can focus on testing the ready components without worrying about what is not yet available. This can give you confidence that the developed components are working correctly.

Later, when the entire API is available for testing, you can quickly verify its functionality without spending a lot of time on testing that has already been covered earlier.

Additionally, you can concentrate on your API’s functioning in connection to other third-party APIs it communicates with during this testing phase. You can make sure your API is operating properly and consistently by evaluating various third-party API behaviours

9.Include security testing:

Security testing should be integrated into the development process as early as possible, to identify and fix security vulnerabilities early on. This can involve using tools such as static analysis tools, dynamic analysis tools, and penetration testing tools to test the security of the software.

These tools can be used to test the security of the software early in the development process.

Run your Puppeteer testing scripts instantly on 50+ browser and OS combinations using the LambdaTest cloud. Read more.

How shift left testing is beneficial?

Below are some of the points, in which shift left testing proves to be beneficial: Reduced time and cost: By starting testing earlier in the development process, organizations can catch defects earlier and reduce the time and cost of testing.

Improved quality:
By testing early and often, organizations can identify and fix defects before they become more complex and expensive.
Enhanced collaboration:
Shift left testing encourages collaboration between development and testing teams, which can improve communication and lead to a better understanding of the requirements and design of the software.
Greater agility: Shift left testing can help organizations be more agile and responsive to changes in the market or business requirements, as it allows them to quickly identify and fix defects and make changes to the software.

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

Conclusion:

Shift Left testing is not a new approach but it has gained more popularity in recent years as organizations have sought to improve the efficiency and effectiveness of their software development processes.It is a valuable approach that can help organizations improve the quality of their software and reduce the time and cost required to develop it.

Cypress .should() Command: A Detailed Guide

BhasinAnshita — Tue, 27 Jun 2023 08:20:31 +0000

An assertion is a way to validate that the application or system under test is functioning as expected. In Cypress, assertions are used to ensure that the state of the application being tested meets the anticipated conditions.

Typically, an assertion consists of two parts: a target value (the actual value being tested) and an expected value (the expected result of the test). If the target value matches the expected value, the assertion passes, indicating that the application functions as expected.

However, if the target value does not match the expected value, the assertion fails, indicating that something is wrong with the application, and the test fails.

_In this Cypress tutorial, I will explain in detail about using Cypress .should() command along with some real time use cases.
_

Quick Recap: What are Assertions?

Assertions are used to define the expected behavior or outcome of a test. When the test results deviate from the expected behavior, the assertions fail, indicating a mismatch between the actual and expected outcomes.

Let’s take an example scenario where you have an eCommerce website, and your objective is to validate that the number of products displayed on the page is exactly 10. But, if you don’t have any assertion in place. You will miss verifying the total count of products which can lead to misleading results.

It is the most important part of test execution. As a tester, your primary responsibility is to ensure the seamless functionality of the application. If the results of the Application Under Test (AUT) do not align with the expected outcome, it is crucial to report any discrepancies as bugs. This practice plays a vital role in upholding the reliability and quality of the application.

Assertions are also important as they contribute to early issue detection, effective debugging, and improved code quality. By incorporating assertions into testing processes, software testers can enhance the overall quality and reliability of the software system. You can learn more about assertions through this tutorial on Cypress assertions.

Here's Top 30+ WebdriverIO Interview Questions and Answers that will help you boost your confidence in an Interview.

What is the use of Cypress .should() Command?

Cypress provides its custom assertion library, which extends the Chai assertion library. One of the assertion commands provided by Cypress is .should().

The Cypress .should() command is used to make assertions about the state of the AUT. It is used to ensure that certain conditions are met before proceeding with the test.

These assertions are automatically retried until they pass or the command times out. This means that if an assertion fails initially, Cypress will retry it until the test passes or the command results in a time out of 4000ms. This makes tests more resilient to flakiness caused by timing issues or network latency.

Syntax

Here are some examples that demonstrate the usage of the Cypress .should() command with cy.get(), cy.contains(), and cy.wrap():

In this blog, I will be using cy.get() for .should() assertion.

Assertion can be handled in different ways. Below are the most commonly used ways you can handle assertion in Cypress.

Assert based on class value
Assert based on length
Assert based on text
Assert based on value tag
Assert based on HTML attribute
Assert for checkboxes
Chaining Multiple Assertions
Assert if the text is visible/hidden
Assert if the value is empty
Assert if the URL is correct
Assert if the element is not present

Let’s understand in detail:

Prepare to ace your Jest interview questions with our thorough set of interview questions and solutions that will enable you to prove your command of the Jest testing framework.

Assert based on class value

To perform assertions where the class of an element can change dynamically based on user interactions or other events, you can use Cypress .should(‘have.class’, ‘className’) command. This command allows you to verify that an element has the expected class. By specifying the desired class name, you can assert whether the element possesses that class as part of your test validation.

It can be useful if the UI changes dynamically based on user interactions or application state. By asserting specific class values, you can ensure the expected behavior is upheld. For example, you can verify whether a button appropriately includes the disabled class when specific conditions require it to be disabled.

An additional scenario where the Cypress .should() command can be utilized is when your application exhibits various states indicated by different class values. In such cases, you can employ assertions to validate the transitions between these states.

For example, you can verify that an element has the loading class during an asynchronous operation and then changes to the loaded class when the operation is complete.

Syntax

It can be used with DOM commands like cy.get(), cy.contains(), or cy.wrap(), as shown below:

Below is an example of how to use the assertion with cy.get() in Cypress.

Test Scenario

Navigate to URL https://ecommerce-playground.lambdatest.io/ using cy.visit().
Enter the email address in a textbox and verify the class value is as expected.
Enter the password in the textbox.
Verify the class value of the submit button is as expected.

Implementation

Below is the Cypress code to open the web application and verify the class using the Cypress .should(‘have.class’,className) assertion.

 describe('Cypress Assertions', () => {
       it('Should - Class Assertion', () => {
           cy.visit(' https://ecommerce-playground.lambdatest.io/')   cy.get('#input-email').type('lambdatest.Cypress@disposable.com').should('have.class', 'form-control')
           cy.get('#input-password').type('Cypress123!!')
           cy.get('[value="Login"]').should('have.class', 'btn btn-primary')
       })
    })

Execution

Code Walkthrough

Step 1

Firstly, the test navigates to the URL of the website using cy.visit().

Step 2

In the below code snippet, the initial step involves selecting the input field with the id input-email. Subsequently, a test email address is entered into the selected field.

Finally, the validation process checks whether the input field possesses the form-control class by utilizing the Cypress .should(‘have.class’, ‘form-control’) command.

It should be noted that although an ID is utilized as a locator in this particular example, you can also create CSS based on other HTML attributes if desired, providing further flexibility.

Step 3

As shown in the screenshot below, the class name of the locator is “form-control” in DOM. So, in Cypress .should(), the same class name is passed along with the locator of the element on the webpage.

Step 4

In the below code, I select the password input field and then type in a test password.

Step 5

The last line selects the login button on the page using a CSS Selector and then checks that it has the classes btn *and *btn-primary.

As shown above, the class value of the locator is “btn btn-primary”, which is passed in the Cypress .should() command.

Get ready for your Mocha interview with our expert-curated list of Mocha interview questions tips. Impress your potential employer and land your dream job!

Assert based on length

In Cypress, if you want to handle a scenario where you want to verify the expected number of elements for a specific set of elements, you can use Cypress .should(‘have.length’,totalLength) command.

For example, it can be helpful in cases where you have multiple products on the page and want to check the length of it or if you wish to verify the number of search results. It is also helpful in cases where you want to check the number of products in a shopping cart.

Syntax

Let’s understand in detail with a test scenario.

Test Scenario

Navigate to the https://ecommerce-playground.lambdatest.io/ webpage using cy.visit().
Verify that there are six categories displayed on the page using the .should(have.length) assertion.
Verify that there are 10 top products displayed on the page.

Implementation

describe('Cypress Assertions', () => {
       it('Should - Length Assertion', () => {
           /* Verify the number of categories on the page */
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('.navbar-nav.horizontal>li').should('have.length', 6)
           /* Verify the number of top products on the page */
           cy.get('.swiper-wrapper').eq(1).find('>div').should('have.length, 10)
       })  })

Execution

Code Walkthrough

Step 1

Firstly, the test navigates to the URL of the website using cy.visit().

Step 2

Then, it verifies that there are six categories displayed on the page using the .should(have.length) assertion on the class value, which is ‘.navbar-nav.horizontal >li’.

In the below screenshot, it can be seen that the category locator with class value ‘.navbar-nav.horizontal >li’ has six results.

Step 3

Next, it verifies that there are 10 top products displayed on the page using the .should(have.length) assertion on the class locator, which is ‘.swiper-wrapper‘.

As shown below in the screenshot, cy.get(‘.swiper-wrapper’).eq(1) is used, which returns the matched element, which is at location 2.

Step 3

It is seen in the below screenshot that the div element count is ten, which is inside cy.get(‘.swiper-wrapper’).eq(1).find(‘>div’).

The below command cy.get(‘.swiper-wrapper’).eq(1).find(‘>div’).should(‘have.length’, 10) searches for the element with class value ‘.swiper-wrapper’, which is at index 1 (or location2) and then finds the div elements and in the end it verifies that the total number of div elements are 10 using .should(‘have.length’,10).

Boost your testing skills with Pytest interview questions. Beginner, intermediate, and advanced levels covered. Prepare and excel in your interviews.!

Assert based on text

In Cypress, if you want to verify the expected text on the page, you can use Cypress .should(‘have.text’,expectedText) assertion. This is one of the most commonly used Cypress assertions.

It is helpful in cases where your application supports multiple languages. In those cases, you can use text-based assertions to verify the correct translation of text elements. By asserting the presence of specific translated text, you can ensure that the application displays the correct language based on the user’s preferences.

This type of assertion is frequently used in testing when a tester needs to verify an expected value, often in the form of text, on a webpage. As such, assertions based on text can be used in a wide range of scenarios where verifying expected text is a critical part of the test case.

Syntax

Test Scenario

Navigate to the website https://ecommerce-playground.lambdatest.io/.
Verify that the text “Upto 30% Off on Popular Smartphones + Exchange Offers” is displayed under the Top Products section.
Verify that the third product displayed under the Top Collection section is “HTC Touch HD”.

Implementation

describe('Cypress Assertions', () => {
       it('Should - Text Assertion', () => {
           /* Verify the text of category on the page */
           cy.visit('https://ecommerce-playground.lambdatest.io/')    cy.get('.m-md-0.d-flex.align-items-center.mb-3').should('have.text', "Upto 30% Off on Popular Smartphones + Exchange Offers")
           /* Verify the text of specific products at specific location on the page */    cy.get('.swiper-slide.swiper-slide-active').eq(2).find('>div>div>h4>a').first().should('have.text', 'HTC Touch HD')
       }) })

Execution

Code Walkthrough

Step 1

Firstly, the test navigates to the URL of the website using cy.visit().

Step 2

It uses the cy.get() command with a class selector to target an element on the page with the class “m-md-0.d-flex align-items-center.mb-3“.

Then, the Cypress .should() command is used with the assertion “have.text” to check that the element contains the expected text “Upto 30% Off on Popular Smartphones + Exchange Offers”.

As shown in the screenshot below, locator values have matching text. It is important to note in the case of Cypress .should(‘have.text’expectedText) assertion, you need to pass the exact text value else your test case will fail. Even if there is space in the text, the test case will fail in that case.

Step 3

The last line of code verifies the text of a specific product located at a specific location on the page. It finds the specific location using class “.swiper-slide.swiper-slide-active’” at location 3. Then it finds the first text, which is under the element (‘>div>div>h4>a‘).

In the end, it asserts the text of the link using the Cypress .should(‘have.text’, ‘HTC Touch HD’)” assertion.

In the below screenshot, it can be seen for the locator with class “.swiper-slide.swiper-slide-active”, which is at 3rd location, inside that div>div>h4>a has specific text, which we are validating in our code.

In summary, this test case navigates to a website and verifies that two elements on the page contain expected text using the Cypress .should() command with the “have.text” assertion.

Ace your QA interviews with our comprehensive guide on 60+ SpecFlow Interview Questions and Answers. Boost your BDD knowledge and showcase your SpecFlow expertise.

Assert based on value tag

It is a common practice in web applications to assert based on the value tag, which sets the initial value of an input element, such as a text input field, to validate whether an element contains a specific value.

This can be easily achieved using the Cypress .should(‘have.value’,expectedValue) command, which verifies whether a particular element has the expected value.

It can be used in cases when you are interacting with select dropdowns. You can verify that the selected option’s value matches the expected value. This is useful for validating the correctness of user selections in dropdown menus.

Syntax

Let’s understand it with the below examples.

Test Scenarios

Test Case 1

Navigate to URL https://ecommerce-playground.lambdatest.io/ using cy.visit().
Enter text in a search box using cy.type().
Verify the entered text value is correct.
Also, Verify if the entered text is not equal to some other value. It is case-sensitive.

Test Case 2

Navigate to URL https://www.lambdatest.com/selenium-playground/select-dropdown-demo.
Select the dropdown value.
Verify the selected dropdown value is as expected.

Implementation

describe('Cypress Assertions', () => {
       it.only('Should - Value Assertion for Textbox', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('input[name="search"]').first().type('iphone')
           cy.get('input[name="search"]').first().should('have.value', 'iphone')
          cy.get('input[name="search"]').first().should('not.have.value', 'IPHONE')


       })


       it('Should - Value Assertion for Dropdown', () => {
    cy.visit('https://www.lambdatest.com/selenium-playground/select-dropdown-demo')
           cy.get('#select-demo').select('Wednesday')
           cy.get('#select-demo option:selected').should('have.value', 'Wednesday')
       })
    })

Execution

Code Walkthrough

Test Case 1

In the first test case, it opens a web application. Enter the text and verify if the entered text value matches the expected value.

Step 1

The first step is to navigate to the URL using cy.visit().

Step 2

Using cy.get(selector), it will find the element and then using .type(‘iphone’), will pass the text to the textbox.

Step 3

After entering the text in the textbox, it verifies if the entered text matches the expected text using .should(‘have.value’,expectedText).

Test Case 2

In the second test case, it opens a web application. Select the value from the dropdown and verify if the selected text value matches the expected value.

Step 1

First step is to navigate to the URL using cy.visit().

Step 2

Using the below code, choose the value of the dropdown. In this case, .select() is used to select the dropdown value.

Step 3

In the end, assert the selected dropdown value is as expected using Cypress .should(‘have.value’,expectedText) command.

Here's Top 30 Robot Framework Interview Questions and Answers that will help you boost your confidence in an Interview.

Assert based on attribute

It’s often important to verify that certain attributes of elements on the page have the expected values.

For example, if you have a link on the page and want to assert that the value of the href attribute is correct, Cypress makes it easy to do this using its built-in .should() function.

To assert based on attribute, you can use the should function with the have.attr property. The have.attr property allows you to check the value of any attribute on an element.

Syntax

Let’s understand with below test scenario:

Test Scenario

Navigate to the URL https://ecommerce-playground.lambdatest.io/.
Select dropdown value.
Verify the selected dropdown value is as expected.

Implementation

 describe('Cypress Assertions', () => {


       it.only('Should - Attribute Assertion for Textbox', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('span:contains("Home")').parents('a').should('have.attr', 'href','https://ecommerce-playground.lambdatest.io/index.php?route=common/home')
           })
    })

Execution

Code Walkthrough

Step 1

In the first step, the cy.visit() command is used to navigate to the specified URL, which is https://ecommerce-playground.lambdatest.io/.

Step 2

I am using the cy.get() command to select the element on the web page containing the text “Home“, which in this case is a span element.

As shown below, .parents(‘a’) Cypress command is used, which traverses up the DOM tree from the span element to select its parent element, which is an ‘a’ tag.

In the end, the Cypress .should() command is used to assert that the a tag selected in the previous step has a specific attribute called href, with a value of https://ecommerce-playground.lambdatest.io/index.php?route=common/home.

So overall, this code navigates to the website, selects the “Home” link, and checks if its href attribute has a specific value.

In this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

Assert for checkboxes

When it comes to testing forms, checkboxes are a common element to be included. As a test automation engineer, we need to assert the expected behavior of the checkboxes in our test cases.

In scenarios where mandatory terms and conditions checkboxes are required for user login, you can utilize the Cypress .should(‘be.checked’) assertion to verify whether the checkbox is selected before proceeding with the login process. This approach ensures that the user can proceed only when the checkbox is checked, the user can proceed.

Additionally, this approach proves useful when you need to confirm that a checkbox has been unchecked. For instance, certain web applications provide a checkbox during registration to receive notifications via email. Users have the option to opt out of this feature. By employing the Cypress .should(‘be.unchecked’) command, you can verify whether the already selected checkbox can be successfully deselected.

Syntax

Let’s understand in detail, using the below scenario on how to write assertions for checkboxes using Cypress.

Test Scenario

Navigate to URL https://www.lambdatest.com/selenium-playground/checkbox-demo.
Select a single checkbox and validate if it got checked.
Select multiple checkboxes on the page.
Verify all the checkboxes got selected/checked.
Uncheck the single checkbox and verify it got unchecked.
Uncheck the multiple checkboxes and verify if they got unchecked.

Implementation


    describe('Cypress Assertions', () => {
       it('Should - Checkbox Assertion', () => {   cy.visit('https://www.lambdatest.com/selenium-playground/checkbox-demo')
           /* select checkbox and verify if it is checked */
           cy.get('#isAgeSelected').check().should('be.checked')
           cy.get('.cb-element.mr-10').check().should('be.checked')
           /* unselect checkbox and verify if it is unchecked */
           cy.get('#isAgeSelected').uncheck().should('not.be.checked')
           cy.get('.cb-element.mr-10').uncheck().should('not.be.checked')
       })
    })

Execution

Code Walkthrough

The above code verifies that the checkboxes on the provided webpage can be selected and unselected correctly.

Step 1

Using the below code, the cy.visit() command is used to navigate to the specified URL, which is https://www.lambdatest.com/selenium-playground/checkbox-demo.

Step 2

As shown in the below screenshot, I am using the cy.get() command to select the element on the webpage along with the .check() command, which is used to select the checkbox. Then, Cypress .should(‘be.checked’) command is used to assert that the checkboxes are checked.

Step 3

In the below code, I am using the cy.get() command to select the element on the webpage along with the .uncheck() command to uncheck the checkboxes.

Then the Cypress .should(‘not.be.checked’) command is used to assert that the checkboxes are unchecked.

Run your Selenium Automation Testing scripts on the LambdaTest cloud grid. Test on 3000+ desktop & mobile environments. Try it for free!

Chaining Multiple Assertions using Cypress .should() Command

In Cypress, you can easily perform multiple assertions on the same element or group of elements using the chaining method. This makes it possible to write more concise and efficient tests.

Let’s understand in detail why Chaining is used:

Chaining in Cypress should be used when you want to perform multiple assertions on an element or a series of actions in a specific order. It allows you to express the expected behavior of your application in a concise and readable manner.

For example, You can use multiple assertions on the same element using the chaining method for a case where you want first to verify if there are eight products on the page. Then you want to perform a second assertion to validate the text of each product.

By chaining multiple assertions together, you can create a sequence of conditions that need to be satisfied for the test to pass. In this case, each assertion in the chain is executed sequentially, and the next assertion is only evaluated if the previous one passes.

It is important to note if any assertion in the chain fails, the test will immediately fail and stop executing further assertions. In Cypress, if there is a failure case in the chain, the test will stop the execution at that point, and the failure will be reported in the test results.

Let’s understand this with the below example of how to perform multiple assertions on an element using the chaining method:

Test Scenarios

Test Case 1

Navigate to the URL https://www.lambdatest.com/selenium-playground/checkbox-demo.
Verify Top Trending Category products on the page are 8 in the count and verify the last element is “MP3 Players” and has CSS “font-family”
Verify search box has the attribute aria-label has the value “Search For Products”.
Enter the text in the search box and verify the entered text is as expected.

Test Case 2

Navigate to URL https://www.lambdatest.com/selenium-playground/select-dropdown-demo.
Select the dropdown value “Wednesday” from a single dropdown and verify that the element got selected and has the same value which was selected.

Implementation

describe('Cypress Assertions', () => {
       it('Should - Multiple Assertion', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('.figure.img-top').should('have.length', 8)
               .last()
               .should('include.text', "MP3 Players").should('have.css', 'font-family')
           cy.get('input[name="search"]').first().should('have.attr', 'aria-label', "Search For Products").type('iphone').should('have.value', 'iphone')
       })
       it('Should - Multiple Assertion for Dropdown', () => {    cy.visit('https://www.lambdatest.com/selenium-playground/select-dropdown-demo')
           cy.get('#select-demo').select('Wednesday')
           cy.get('#select-demo option:selected').should('be.selected').and('have.value', 'Wednesday')
       })
    })

Execution

Code Walkthrough

Test Case 1

Step 1

Using the below code, the cy.visit() command is used to navigate to the specified URL, which is https://ecommerce-playground.lambdatest.io/.

Step 2

The first assertion cy.get(‘.figure.img-top’).should(‘have.length’, 8) verifies that there are eight elements with the class “figure img-top“.

The second assertion .last().should(‘include.text’, “MP3 Players”) verifies that the last element with the class “figure img-top” contains the text “MP3 Players”.

The third assertion .should(‘have.css’, ‘font-family’) verifies that the font family of the last element with the class “figure img-top” is defined.

Step 3

As per the below code, first assertion cy.get(‘input[name=”search”]’). first().should(‘have.attr’, ‘aria-label’, “Search For Products”) verifies that the first input element with the name attribute “search” has an aria-label attribute set to “Search For Products“.

The second assertion .type(‘iphone’).should(‘have.value’, ‘iphone’) types the value “iphone” into the first input element with the name attribute “search” and then verifies that the input value is set to “iphone“.

Test Case 2

Step 1

First, I am navigating to the specified URL, which is https://www.lambdatest.com/selenium-playground/select-dropdown-demo using cy.visit().

Step 2

As per the below code, cy.get(‘#select-demo’).select(‘Wednesday’) selects the option “Wednesday” from the dropdown menu with the ID “select-demo“.

Step 3

The below code cy.get(‘#select-demo option:selected’).should(‘be.selected’).and(‘have.value’, ‘Wednesday’) verifies that the selected option is “Wednesday” and that it is marked as selected.

Do you need to gather more knowledge on website testing? LambdaTest is here to explain further.

Assert if the text is visible/hidden

To verify if the DOM element is visible on the page. In Cypress, .should(‘be.visible’) command is used. This assertion can be used to ensure that certain UI elements are displayed correctly and that the user can interact with them as expected.

This is helpful in cases where you want to verify the content on the page. For example, after successful registration, you can verify if the name is the same, which was entered while registering. It can also be used in cases where you want to verify that a successful message is displayed or not

You can check both the cases about visibility and non-visibility of an element.

For non-visibility, it can be helpful in cases where you want to verify if an element does not exist on the page. For example, if you want to verify the error text on the page does not exist. In that case, you can use the Cypress .should(‘not.be.visible’) command.

Syntax

Let’s understand the below test scenario.

Test Scenario

Navigate to the URL https://ecommerce-playground.lambdatest.io/.
Verify on the web page that the category “Home” is visible.
Verify if a modal dialog is hidden on the page.

Implementation

 describe('Cypress Assertions', () => {
       it.only('Should - Visibility Assertion', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('span:contains("Home")').should('be.visible')
           cy.get('.modal-dialog').should('not.be.visible');
           }) })

Execution

Code Walkthrough

Step 1

Using the below code, the cy.visit() command is used to navigate to the specified URL, which is https://ecommerce-playground.lambdatest.io/

Step 2

As per the code in the below screenshot, I am using the cy.get() command to select the element on the webpage along with the Cypress .should(‘be.visible’) command, which asserts that the text is visible on the page.

Step 3

As per the code in the below screenshot, I am using the cy.get().should(‘not.be.visible’) command to check that a modal dialog is hidden: Modal dialogs are often used in web applications to display important messages or prompts to the user.

It is important to note that by using the Cypress .should(‘not.be.visible’) assertion, you can ensure that it is hidden from the user when it is not needed.

Perform browser automation testing on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Assert if the value is empty

In Cypress if you want to verify if a value is empty or not, based on the value for the input field or text content or URL. You can use Cypress .should(‘be.empty’) command.

Some of the most common use cases where Cypress .should(‘be.empty’) can be used are:

Validating Cleared Fields
Verifying Empty Lists or Tables
Testing Empty Input Fields

Syntax

Test Scenario

Navigate to the URL https://ecommerce-playground.lambdatest.io/.
Verify the URL hash is being used correctly.

Implementation

describe('Cypress Assertions', () => {


       it.only('Should - Empty Assertion', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.hash().should('be.empty')
       })
    })

Execution

Code Walkthrough

Step 1

Using the below code, the cy.visit() command is used to navigate to the specified URL, which is https://ecommerce-playground.lambdatest.io/.

Step 2

cy.hash() is a command that retrieves the current URL hash. The URL hash is part of the URL that comes after the “#” symbol, and it is often used to store data that is used by JavaScript on the client side.

The Cypress .should(‘be.empty’) assertion checks that a value is empty. When applied to cy.hash(), it checks that the current URL hash is empty.

In the below code, this assertion is used to verify that a page has not been loaded with a specific URL hash.

This tutorial dive deep into web testing to help you understand its life cycle, elements, angles, the role of automation, and more.

Assert if the URL is correct

As a tester, one of the most common assertions you perform is verifying if the URL of the page is valid. There are no additional parameters added to the URL after opening the web application.

If you want to verify the URL, there is Cypress .should() assertion, which can be used with cy.url(). You can either match the exact URL or match some of the URL contents using cy.url().should().

Syntax

Test Scenario

Navigate to the URL https://ecommerce-playground.lambdatest.io/.
Verify that the URL of the website is the same as the expected text.
Verify that the URL of the website includes the expected text in the URL.

Implementation

Execution

Code Walkthrough

Step 1

Firstly, it opens the web application using cy.visit().

Step 2

Then, it asserts that the URL of the website is exactly equal to
https://ecommerce-playground.lambdatest.io/ using cy.url().should(‘eq’,
“https://ecommerce-playground.lambdatest.io/”).

Step 3

In the end, use cy.url().should(‘include’, “https://ecommerce-playground”) asserts that the URL of the website includes the string “https://ecommerce-playground”.

It is important to note that the above assertion doesn’t look for exact text. It checks if the passed text is present in the URL or not, whereas, in the first assertion, it tries to match the exact URL passed.

You need to choose it as per the requirement if the URL keeps updating based on the parameters. In those cases, include assertion cy.url().should(‘include’,URL) can be used, but if you have a fixed URL. you can directly use cy.url().should(‘eq’,URL).

Assert if the element is not present

If you want to verify if an element is not present on the page, you can use the Cypress .should(‘not.exist’) assertion. It is one of the most useful assertions and my personal favorite ,when you want to verify the absence of an element on the page, such as when testing error messages, pop-up notifications, or elements that should be hidden or removed based on certain conditions.

In certain scenarios, a pop-up may appear on a web page when it is loaded, but it disappears after a certain period of time. In such cases, the Cypress .should(‘not.exist’) assertion proves to be extremely valuable as it allows you to verify the visibility of the pop-up.

For instance, consider a situation where a pop-up message is displayed upon page load, providing important information or updates to the user. After a brief moment, the pop-up disappears automatically. By using the Cypress .should(‘not.exist’) assertion, you can ensure that the pop-up is no longer present in the DOM, indicating that it has disappeared from the user’s view.

Syntax

Test Scenario

Navigate to the URL https://ecommerce-playground.lambdatest.io/.
Enter Iphone in the search box.
Verify search results do not have “Samsung”.

Implementation

 describe('Cypress Assertions', () => {


       it('Should - Multiple Assertion', () => {
           cy.visit('https://ecommerce-playground.lambdatest.io/')
           cy.get('[placeholder="Search For Products"]').first().type('iphone')
           cy.get('.dropdown-menu.autocomplete.w-100').contains('samsung').should('not.exist')


       })
    })

Execution

Code Walkthrough

Step 1

Using the below code, the cy.visit() command is used to navigate to the specified URL, which is https://ecommerce-playground.lambdatest.io/.

Step 2

In the below code, it selects the first input field with the placeholder text Search For Products and then types iphone.

Step 3

In the below code, it checks for text Samsung in the dropdown and then verifies if Samsung does not exist.

It is important to note that by adding Cypress .should(‘not.exist’) to any DOM command, Cypress will reverse its default assertion and automatically wait until the element does not exist.

For the cases where the element is present in the DOM but hidden from view, the Cypress .should(‘not.exist’) assertion will fail. In such cases, you may need to use other assertions, like visibility assertions, to handle elements that are hidden but still present in the DOM.

When leveraging the powerful Cypress .should() command, you can enhance your test automation by performing precise assertions, ensuring the desired behavior and quality of your application in the cloud-based testing environment.

Cloud testing platforms like LambdaTest allow you to perform Cypress automation at scale over an online browser farm of 3000+ browsers and operating systems. You can further optimize and reduce your test execution time by harnessing the power of Cypress parallel testing.

Test native, hybrid, and web apps on any mobile OS with our free Android emulator online. Sign up to optimize app performance.

Note: Here is our support documentation to help you get started with Cypress testing

Are you ready to elevate your Cypress automation skills? Join our specialized Cypress 101 certification course, tailored for developers and testers seeking to expand their expertise in Cypress test automation. Gain advanced knowledge and sharpen your skills to unlock new possibilities in your test automation journey.

Conclusion

Cypress UI automation framework offers a versatile and robust assertion method, .should(), that empowers you to perform a wide range of assertions based on various use cases. From verifying element visibility and content to examining attributes, CSS properties, URLs, and hash values, Cypress .should() provides a flexible and powerful approach to writing assertions. By leveraging this capability, you can enhance the quality and reliability of your web application by validating critical aspects and ensuring they meet the desired expectations.

Strategy for starting Test Automation in an organization

BhasinAnshita — Mon, 26 Jun 2023 10:44:30 +0000

A well-crafted test automation strategy is essential for any organization or enterprise striving to provide top-quality products or services. Today, where we want a major chunk of test cases to be automated, the main painful area for every QA is understanding where to start.

Through my personal experience, I have witnessed that many individuals struggle with initiating automation.While they may be familiar with the latest tools and technologies available in the market, selecting an automation tool and adopting a CI/CD approach is insufficient. Instead, they require a deeper understanding of where to commence automation.

In an organization where no test strategy has been defined, testers may find it challenging to begin automation because they lack a clear starting point ,especially If there are a large number of test cases to work on and they don’t know which one to pick first for the automation or how to start and where to start.

This problem can be particularly challenging in an agile methodology, where short sprints require strategic planning to ensure that automation work is completed on time. In my experience, I have seen many people struggling to begin automation because they lack a clear plan for strategizing. Without a roadmap, they can feel lost and uncertain about where and how to begin.

So, in this blog I will guide you in planning the automation strategy for existing components in your organization.

It is essential to plan the process before automating the test cases in any organization. If you are new to a team/squad in an organization and are unaware of the scope of testing for your team/squad, then it can be challenging for you to start the automation.However, with a well-planned strategy in place, the process can be done efficiently and effectively.

While working with one of my previous organizations, I faced a challenge where many teams were contributing to a single application. I knew which tech tools, which framework and which CI/CD I had to use but the issue was to identify what are the components/modules which were under my scope of testing.

So, based on my extensive background in QA, I have developed a four-step plan which I put into action while working with one of my previous organizations. This plan helped me gain clarity on the components/modules under my testing scope and their corresponding test case requirements, even though many teams were contributing to a single application. By following this strategy, I observed a significant improvement in my automation efforts.

Ace your Protractor interview with these 50+ Protractor interview questions. Boost you confidence and land your dream job with this comprehensive guide.

A four-step strategy for starting test automation in an organization

Identify the scope of testing
Prioritize the testing scope
Write test cases
Test Execution Strategy
We will see in detail the step-by-step process.

1. Identify the scope of testing

In an organization, if you are working in an agile methodology there can be different divisions like Teams/Squads that handle the respective components and different teams/squads can contribute to a single web application. In that case, it becomes difficult for QA engineers to finalize the scope of testing with respect to their teams/squads.

Let’s try to understand with a real-time example.

Taking the example of an e-commerce application, there can be multiple teams/squads working on it. One team/squad may handle the user profile, and another might handle the checkout. But these are all part of a single web application and you are the QA for the core team (Let’s say “marketplace”). FYI: Marketplace covers end-to-end web applications but there are other teams/squads involved in adding functionality to the web application and their QA is responsible for the functional testing.

So, the issue that arises is–who takes ownership? If you are the QA of the leading team, are you responsible for the whole end-to-end testing?

In order to decide this, it is always good to communicate within the team and define the scope of testing for your team/squad, which is the first step in planning QA automation.

As part of step 1, we should have a meeting involving PM/PO, leads, and QA and define the scope of testing. As part of this step, you can prepare a table with 3 columns ( as shown below) which is the prerequisite to joining the meeting, and then you can discuss and finalize the scope of testing for different teams/squads. As QA, you should take ownership of this meeting and finalize the scope.

Make sure you are prepared before going to the meeting so that you make proper use of everyone’s time.

So, as per the above table, we see there are 2 components but there are 2 different teams/squads that are responsible for automating the test cases. So, the outcome of this meeting is we have the scope ready and we know clearly which team/squad will handle the automation of the respective components.

You can create a confluence page with the above table or upload the table on any shared portal in your organization like SharePoint. Uploading it on a common platform like Confluence will help you to share it easily with others and let anyone view it anytime.

Be it the test plan or automation test cases, it is always a good idea to upload it on the shared platform so that all the team members in the organization can view it. If you have it on the local machine, it won’t add that much value to the work you are doing.

Ace your Cypress interview questions with these 60+ Cypress interview questions. Boost you confidence and land your dream job with this comprehensive guide.

2. Prioritize the testing scope components

Your job does not end after defining the scope of testing. Now, you have all the components ready that you have to automate but which one to pick first for automation, is the next question. So, in order to decide which component should be picked up first for the automation, we need to know the priority.

There are various factors involved in prioritizing the test cases for automation but it is recommended to involve all the members (PM/PO, Leads, QA). Everyone’s input is important in defining the priority. PM/PO would know from the business perspective which area is highly important. The team lead can provide inputs with respect to technical scope and QA knows whether this can be automated or not.

So, as part of this step, there would be brainstorming among all the members and then you can prioritize the test cases.

The table would look something like the below:

P0 would be the component that needs to be automated first, followed by P1, P2, and P3.

Again, the above table should be created as a Confluence page or should be uploaded on the shared platform which is used in your organization.

3. Write test cases in the test management tool

By now, you have the components ready and you know the priority of the test components. The next step is writing the test cases using any test management tool.

As automation engineers, we sometimes tend to ignore this step because it seems boring to write test cases and save them, but it is imperative with respect to tracking the test cases.

If you are automating the test cases but not writing them, how will your PM or other team members know? Not everyone is interested in looking at your code. By writing test cases, you can link them to the project management tool you follow in your organization and everyone would have visibility about the test cases which are related to the story.

Get ready to ace your Selenium interview questions in 2023 with our comprehensive list of 90 questions and answers that will help you sharpen your testing skills.

4. Test Execution Strategy

Once you have the test cases and you know the priority of the test cases. The next step is to plan the test execution. The objective of a Test Execution Strategy is to provide a comprehensive plan for the execution and maintenance of the automated tests, ensuring the quality and efficiency of the testing process.

Deciding the test execution depends on several factors such as:

Test requirements: The framework should support the testing needs and requirements of your project.
Test Tools: Identify the test automation tools to be used for execution and any dependencies required. If you want to go for the open-source tool. You need to decide which tool is best for the team depending on the factors like language ( It’s Java or Javascript or Python) and its Integration with CI/CD
Test Data: Determine the test data that needs to be created and managed for the automated tests. Gather all the test data required for testing ( Example: user details If you want to login into a web application and perform testing and If you are checking multiple countries then all the country URLs)
Test environment: Manually check if a web application is stable or not. The environment you are working on should not throw any server issues. Check if the environment does not have features like a captcha (which can’t be automated)
Test Maintenance: Establish a process for maintaining the automated tests, including regular reviews, updates, and bug fixes.

Before you start the automation, It is always advisable to manually test the application. You cannot directly start writing the code without understanding if the environment is stable and if you have all the required test data.

If you follow all 4 steps above. You would know the test cases (which are the candidates for automation), and the priority of test components with respect to automation and then you can easily start the automation of the test cases based on the priority of the cases.

If you are preparing for a Playwright automation interview, this list of Playwright interview questions can help you get a list of the most asked questions with detailed answers.

Strategies to speed up the test automation

Starting an automation process can also be a challenging part if you don’t know where to start. Above mentioned steps is the prerequisite if you are planning to start test automation in your organization.

After you have identified the areas of the organization that would benefit most from automation, such as processes that are time-consuming, error-prone, or repetitive, you can then follow a few other potential strategies which will benefit you:

Develop a plan for implementing automation in the selected areas. This plan should include the specific tools and technologies that will be used, the processes that will be automated, and the resources that will be required. It should also include a timeline for implementing the automation and any potential challenges or risks that need to be addressed.
Train and support the staff who will be using automation tools and technologies. Automation can be a significant change for many organizations, and it is important to ensure that staff is properly trained and supported so that they can use the automation tools effectively and efficiently.
Monitor and evaluate the results of the automation implementation. This can help to identify any problems or issues that need to be addressed, as well as any opportunities for further improvement or expansion.
Continuously improve and expand the automation implementation over time. As the organization learns more about automation and gains experience with it, it can continue to refine and improve its automation strategy, tools, and processes to achieve even better results.

Here's Top 30+ WebdriverIO Interview Questions and Answers that will help you boost your confidence in an Interview.

Conclusion

In conclusion, the test strategy for starting a QA automation process is a crucial aspect of software development. It requires a systematic and well-planned approach to ensure that the automation process is effective, efficient, and meets the project requirements and user expectations. By following a structured approach, organizations can establish a solid foundation for their QA automation efforts, leading to higher-quality software and a better user experience.

Prepare to ace your Jest interviews with our thorough set of Jest interview questions and solutions that will enable you to prove your command of the Jest testing framework.

Running Tests In Cypress With GitHub Actions [Complete Guide]

BhasinAnshita — Fri, 23 Jun 2023 07:42:15 +0000

In today’s tech world, where speed is the key to modern software development, we should aim to get quick feedback on the impact of any change, and that is where CI/CD comes in place.

Setting up CI/CD is crucial for automated test cases because it gives more consistent results, agility, and efficient assessment of minor changes. With the shorter release and fast development cycles, we need to check that automated tests are passing on every code change, which can be easily done by configuring the CI/CD pipeline.

Let’s try to understand the impact of CI/CD with an example here:

You want to execute the automation suite whenever anyone pushes the code in the Git repository. So, how will you do that?

With no CI/CD set up for your project

To run the automation suite, you have to pull the latest code and then run it locally on your machine, which is a tedious and lengthy process.

With CI/CD implemented

You will set up your project’s CI/CD pipeline. So, your automation test suite would run whenever anyone pushes a code or creates a pull request automatically. It will take the latest code from the Git repository and run the test.

Setting up CI/CD helps to save time. Over the past few years, DevOps has become an important part of the software life cycle, leading to the growth of various DevOps tools and practices.

There are many CI/CD tools available in the market used by automation testers, but these days most people are using GitHub for version control and collaboration. So, GitHub Actions is becoming the favorite choice for automation testers/developers for CI/CD.

GitHub Actions is offered by GitHub as a SaaS offering. With GitHub Actions, you can achieve scheduling, parallelization, run your tests on Docker Containers, and can do many more.

In this blog on Cypress with GitHub Actions, we will learn how to set up CI/CD pipeline for Cypress test cases using GitHub Actions.

What is Cypress?

Cypress is an open-source framework, which is built on Node.js and comes packaged as an npm module. It uses JavaScript for writing the test cases. As it runs tests directly inside the browser, it is fast compared to the other automation testing tools (or frameworks).

Cypress automation tool has received huge acceptance from QA and Developers and is constantly gaining popularity due to its features like easy installation, easy debugging, real-time reloads, and ease of use.

Below are some of the features, which make it unique from other web automation tools in the market:

Easy Installation.
Easy Debugging.
In-built support for Retries, Screenshots, and Videos (No Extra code needs to be written).
Automatic Reload (Cypress reloads your test case whenever you make any changes to your script).
Can easily run your tests on different viewports ( iPad, iPhone, Samsung).
Flake Resistant (Cypress waits for commands and assertions before moving on to the next step which avoids flakiness in a test).

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to Python automation testing to help you streamline your testing process.

What is GitHub Actions?

GitHub Actions is a Continuous Integration (build, test, merge) and Continuous Delivery (automatically released to the repository) (CI/CD) platform. It automates and executes the software development workflows right from GitHub.

With GitHub Actions, you can build, test, and publish across multiple platforms, operating systems, and languages all within the same workflow and then see the status checks displayed within the pull request.

All GitHub Actions are handled via workflows, which are .yml files placed under the .github/workflows directory in a repository that defines automated processes. It brings automation directly into the software development lifecycle via event-driven triggers such as creating a pull request or pushing a code into a remote branch.

With GitHub Action, the pain of keeping your plugins updated is gone (which is the issue for other CI/CD tools like Jenkins), You don’t have to go to a separate tab for running CI/CD and pushing your code. It is all done in GitHub.

Some of the features of GitHub Actions are:

Ease of setup. There is no installation required as it is on the cloud.
Support of multiple languages and frameworks.
Provides actions to every GitHub event.
It can be shared via GitHub Marketplace.
No explicit plugin is required for caching. You can write your own caching mechanism if you require caching.
Asynchronous CI/CD is achieved using GitHub Actions.

At present, GitHub Actions is free to use for public repositories, and for private, it has a pay-as-you-go mechanism.

We can speed up the software validation process and boost testing coverage by adopting automated testing. However, there are a lot of challenges in test automation.

How to setup GitHub Actions in your Git repository?

GitHub Actions lets you run workflows when a certain triggering event occurs such as a code push, or pull request. A GitHub repository can have multiple workflows. For example, we can create 1 workflow to run our test case whenever there is a code push and one workflow to test the pull requests.

As part of this Cypress with GitHub Actions tutorial, we will learn how to set up the GitHub Action pipeline whenever there is a code push to the remote branch.
Reference code can be found here:

Below are the steps to set up GitHub Actions in the Git repository:

Login to your GitHub account.
Create a workflow: Click on Add file > Create new file.
Enter .github/workflows/main.yml ( It has to be in the same sequence). main.yml is the file name, you can name it as per your choice.
Create a workflow file.

Follow the below sample code to create a GitHub Actions workflow (.yml file)

  name: Add Action
    on:
     push:
       branches:
         - main
    jobs:
     Cypress-Test:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout GitCode
           uses: actions/checkout@v2

name => It is the name of the workflow file. It appears in the “Actions” tab of the GitHub Repository with the same name.
on=> On is the trigger condition, it specifies the trigger for the workflow. We have to add the events (push, pull_request, etc.) as subsections. In the above example, the workflow would be triggered whenever anyone pushes a change to the repository.
jobs=> Groups all the jobs/tasks that are defined inside the job section in the yml file. We can define the name of jobs just in the next line.
runs-on: ubuntu-latest => It configures the job to run on the latest version of Ubuntu. The job will execute on a fresh virtual machine hosted by GitHub. You can configure any value of the OS where you would like to execute the GitHub Actions workflow on.
Steps=> It groups together all the steps that are defined in the yml file. There can be multiple steps in a .yml file. It is placed at the same level as the on section.
Uses=>Syntax to use the GitHub Actions in the .yml file. You can pass the GitHub Actions to run the test case/ to checkout the code.

Now if you add this simple workflow to your repo, and push your code on the main branch, you can check that a workflow has been added under the Actions tab.

If you click on the workflow run, you’ll see some details such as the commit, the status, the time duration, as well as the jobs that have run.

As per the above screenshot, we have only 1 job, i.e., Cypress-Test. We can also view the logs about setting up the job and completing it just by clicking Cypress-Test.

If you want to explore more on the workflow syntax. You can check here.

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to Python automation testing to help you streamline your testing process.

How to run Cypress tests using GitHub Actions?

Cypress is a test automation tool for web applications, and GitHub Actions is a service that allows developers to automate various tasks, such as building, testing, and deploying code. Using Cypress with GitHub Actions allows us to automate the testing of a web application as part of the continuous integration and continuous deployment process. This can help ensure that the application is working properly and save time and effort for the development team.

To use Cypress with GitHub Actions, you would need to create a workflow file that defines the steps for running your Cypress tests. This file would be stored in your GitHub repository and would be executed by GitHub Actions whenever a specified event, such as pushing code to the repository, occurs.

We will see step by step, how to run the tests using Cypress with GitHub Actions.

Pre-Requisites:

GitHub Repository with working Cypress code
Knowledge of Cypress

Test Scenario:

Open URL. https://ecommerce-playground.lambdatest.io/index.php?route=account/login%22
Log in to the application.
Search the product.
Verify the searched product.

Below is the Cypress end-to-end test code where the user opens the browser, searches for a product, and verifies it in the end.

describe("Automation using Cypress", () => {
     it("Open website and enter username, password", () => {
       cy.visit(
         "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
       );
     });
     it("Login into the application using credentials", () => {
       cy.get('[id="input-email"]').type("lambdatest.Cypress@disposable.com");
       cy.get('[id="input-password"]').type("Cypress123!!");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("Search the Product", () => {
       cy.get('[name="search"]').eq(0).type("Macbook");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("Verify Product after search ", () => {
       cy.contains("Macbook");
     });
    });

In order to run the above code locally through the terminal, we would run the command “npx cypress run”.

It will run the Cypress test automation and show you the test result in the terminal just like shown below:

Let’s learn how to run the above tests using Cypress with GitHub Actions. If you have followed setting up GitHub Actions in the above section of this blog on Cypress with GitHub Actions, by now you would know how to create a workflow .yml file.

Follow the below code to run the tests using Cypress with Github Actions:

name: Cypress Tests
    on: [push]
    jobs:
     Cypress-Test:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout GitCode
           uses: actions/checkout@v2

         - name: Run Cypress Test
           uses: cypress-io/github-action@v4
           with:
             command: npx cypress run
             browser: chrome

In order to run it using Cypress with GitHub Actions workflow, we will use the Cypress official GitHub Actions (cypress-io/github-action@v4) (ref : Line11)

We have provided the name of the workflow as “Cypress Test”.
We provided the trigger condition, In the above case, it would be pushed. So, whenever there would be code push to the remote branch, this workflow would be executed.
Jobs’ name is passed as “Cypress Test” under which we are providing the OS info to run it on the latest ubuntu OS.
There are 2 steps added as part of the shared workflow .yml file.

The first step, would checkout the code from the GitHub repository using GitHub Actions “actions/checkout@v2”.
The second step would run the Cypress tests. Cypress has official GitHub Actions for running the Cypress tests, which is “cypress-io/github-action@v4”. This action provides npm installation, custom caching, and additional configuration options and simplifies the setup of advanced workflows using Cypress with GitHub Actions platform.

The above workflow would be called whenever there will be code push in your remote GitHub repository.

Once, the workflow is run. You can view the workflow run status from the Actions tab in your GitHub Project just as shown in the below screenshot.

You can also check the step-by-step summary of each GitHub Actions just by clicking the file name and it will take you to the summary screen.

cypress-io/github-action@v4.x.x . . is the Cypress official GitHub Action. By default, it:

Install npm dependencies.
Build the project (npm run build).
Start the project web server (npm start).
Run the Cypress tests within our GitHub repository within Electron.

In this Selenium with Java tutorial, you will learn everything you need to know to kick start your journey in Selenium automation testing with Java.

How to run the Cypress Test Case on a cloud platform using GitHub Actions?

There are multiple approaches to perform Cypress testing on a cloud testing platform like LambdaTest using GitHub Actions.

Continuous quality cloud testing platforms such as LambdaTest lets you perform manual and automation testing of your websites and mobile applications on an online device farm of 3000+ real browsers, devices, and platform combinations. It provides developers with the ability to run their automated tests using different automation testing frameworks including Selenium, Cypress, Playwright and more.

Jenkins is an open-source automation server that is written entirely in Java. Learn how to do continuous integration with Jenkins with this comprehensive guide to Jenkins Tutorial.

One of the ways is using the command as part of Cypress with GitHub Actions.

Below is the Cypress end-to-end testing code, which I would run in the LambdaTest cloud platform.

 describe("Automation using Cypress", () => {
     it("Open website and enter username, password", () => {
       cy.visit(
         "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
       );
     });
     it("Login into the application using credentials", () => {
       cy.get('[id="input-email"]').type("lambdatest.Cypress@disposable.com");
       cy.get('[id="input-password"]').type("Cypress123!!");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("Search the Product", () => {
       cy.get('[name="search"]').eq(0).type("Macbook");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("Verify Product after search ", () => {
       cy.contains("Macbook");
     });
    });

To run the Cypress UI tests on the LambdaTest Platform, we need to do the configuration using 3 steps.

Step 1: Install LambdaTest CLI.

Install LambdaTest CLI using npm, use the below command:

npm install lambdatest-cypress-cli

Step 2: Set up the config.

Once the LambdaTest CLI is installed, now we need to set up the configuration using the below command:

lambdatest-cypress init

After running the command, there will be a file created in your project named “lambdatest-config.json”. We need to set up the configuration in order to run our test case on different browsers on LambdaTest.

auth: We need to set up the LambdaTest credentials, which will be used in lambdatest-config.json to run my test case on the cloud platform.
browsers: Need to specify the browser and OS version on which we want our test case to run.
run_setting: Need to set up the config in run_settings.
Set up the config name, which would differ based on different Cypress Versions, and set up the spec file.

  {
      "lambdatest_auth": {
         "username": "user.name",
         "access_key": "access.key"
      },
      "browsers": [
         {
            "browser": "Chrome",
            "platform": "Windows 10",
            "versions": [
               "latest-1"
            ]
         },
         {
            "browser": "Firefox",
            "platform": "Windows 10",
            "versions": [
               "latest-1"
            ]
         }
      ],
      "run_settings": {
         "config_file": "cypress.config.js",
         "reporter_config_file": "base_reporter_config.json",
         "build_name": "Cypress-Test",
         "parallels": 1,
         "specs": "./cypress/e2e/*/*.cy.js",
         "ignore_files": "",
         "network": false,
         "headless": false,
         "npm_dependencies": {
            "cypress": "11.2.0"
         }
      },
      "tunnel_settings": {
         "tunnel": false}}

Step 3: Execute Test Case

Once the config is done, now you can execute the Cypress test case on the LambdaTest cloud Platform. You just need to run the below command to run it on LambdaTest.

lambdatest-cypress run

After the command is run and test cases are executed successfully, you can view the Cypress test run on LambdaTest cloud platform (Just like shown in the screenshot below):

You can also view the logs by navigating to the logs section.

Until now, we learnt how to run Cypress automation tests on the LambdaTest cloud platform using the IDE terminal. Let’s see how to run the above flow using Cypress with GitHub Actions.

In order to run it using Cypress with GitHub Actions workflow, we will use the Cypress official GitHub Actions (cypress-io/github-action@v4), which either works on the script passed in the package.json or directly picks the cypress commands passed in the .yml file.

So, we will create a script in package.json. In order to run the Cypress test on the LambdaTest cloud platform, we need to run the command “lambdatest-cypress run”.

The same command, we will create as a script in package.json just as shown below:

  {
     "name": "cypress_github-actions-example",
     "version": "1.0.0",
     "description": "test automation using cypress",
     "main": "index.js",
     "scripts": {
       "test": "lambdatest-cypress run"
     },
     "repository": {
       "type": "git",
       "url": "https://github.com/Anshita-Bhasin/Cypress_Github-Actions.git"
     },
     "author": "Anshita Bhasin",
     "license": "ISC",
     "devDependencies": {
       "cypress": "^11.2.0"
     },
     "dependencies": {
       "lambdatest-cypress-cli": "^3.0.7"
     }}

To test if the above script is working fine, Go to the terminal and execute the command “< npm run scriptname >”

For the above code, the command would be npm run test. If you see the tests result just as shown below, that means your script is absolutely working fine.

To run the same using GitHub Actions.

Go to the workflow .yml file. (We covered above, how to create a .yml workflow file)
Pass the script name as a command :

 name: Cypress Cloud Tests
    on: [push]
    jobs:
     Cypress-Test:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout GitCode
           uses: actions/checkout@v2

         - name: Run Cypress Test
           uses: cypress-io/github-action@v4
           with:
             command: npm run test

Command basically runs the Cypress command to execute the Cypress tests. It will check in package.json if there is a command with the name “test” and then it will run, else it will throw an error.

After creating the workflow, you can check the Actions tab in your GitHub Repository. It will show the summary of the workflow run.

Now, navigate to the LambdaTest cloud platform to ensure whether tests are executed or not. You should be able to see the latest build on LambdaTest.

Here’s a guide on how to automate Android app testing using Appium, a powerful framework that can help you streamline your testing process. Learn more now.

How to run Cypress tests for the specific browser using GitHub Actions?

You can also run tests on different browsers using Cypress with GitHub Actions. Just provide the Cypress-supported browser name on which you want to run your test case. As part of the code below, I have passed Firefox. So, the test case would run on the Firefox browser but you can pass Chrome, Electron, or any other browser which Cypress supports.

 name: Cypress Test on Firefox
    on: [push]
    jobs:
     cypress-run:
       runs-on: ubuntu-20.04

       name: E2E Test on Firefox
       steps:
         - uses: actions/checkout@v2
         - uses: cypress-io/github-action@v4
           with:
             browser: firefox

Once the above workflow is executed, you can go to the Actions tab and view the logs where you should be able to see the browser name. It should be the same as passed in the workflow file. Below is the sample screenshot of the workflow logs:

How to run Cypress tests in Docker Container GitHub Actions?

You can also run the Cypress tests in your Docker Container using GitHub Actions. There is already a docker image available online with chrome version 78 and Firefox version 70 pre-installed. You can pass the container image using an argument container. After executing the test cases, it also stops the container.

Below is the sample code to run the Cypress test in the docker container using GitHub Actions:

name: Cypress Test in custom container
    on: [push]
    jobs:
     cypress-test:
       runs-on: ubuntu-20.04
       name: Cypress Tests on docker container
       # Cypress Docker image with Chrome v78
       # and Firefox v70 pre-installed
       container: cypress/browsers:node12.13.0-chrome78-ff70
       steps:
         - uses: actions/checkout@v2
         - uses: cypress-io/github-action@v4
           with:
             browser: chrome

How to get the Cypress test run results using GitHub Actions Artifacts?

You can get the Cypress test result as an artifact after your workflow is executed. You can store the generated videos or screenshots as CI artifacts. Let’s take an example — you want videos of your test run after every run but you want screenshots only when your test fails. So, this can be done by passing conditions in the workflow. We will use GitHub Actions actions/upload-artifact@v2 for storing the artifacts and then will pass the condition to show the artifacts.

Below is the sample code.

 name: Cypress Artifacts
    on: [push]
    jobs:
     cypress-run:
       runs-on: ubuntu-latest
       name: Test Artifacts
       steps:
         - uses: actions/checkout@v2
         - uses: cypress-io/github-action@v4
         - uses: actions/upload-artifact@v2
           if: failure()
           with:
             name: cypress-screenshots
             path: ./cypress/screenshots
         - uses: actions/upload-artifact@v2
           if: always()
           with:
             name: cypress-videos
             path: ./cypress/videos

After your workflow is executed, you can check the artifacts from the summary of the workflow.

Click on the Actions tab. Select the action for the desired workflow run. Click the workflow and it will navigate to the summary page.

Conclusion

Cypress is compatible with different CI tools available in the market but one of the leading ones is GitHub Actions. Cypress even has its official GitHub Action(cypress-io/github-action@v4.x.x) which installs the npm dependency and runs the Cypress test. Running your Cypress test case on CI/CD platform gives you leverage to schedule it and run it on different trigger events which save a lot of time.

As part of this blog on Cypress with GitHub Actions, we covered the scenarios where we executed the Cypress test cases using GitHub Actions and also covered running it on a cloud platform.

Stay tuned for the next topics on the Cypress with GitHub Actions Series. Where the topics like test case scheduling, slack notification, and uploading results on AWS S3 Bucket using GitHub Actions would be covered.