Page History
Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Info | ||
---|---|---|
| ||
|
Note | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Overview
Cypress is a javascript JavaScript based testing framework for test automation. Cypress is often compared to Selenium, but it is different, ; unlike Selenium that is executed outside of the browser Cypress is executed within it, in the same run loop as your application.
Cypress runs in a Node NodeJS server process that allows Cypress and the Node NodeJS server to constantly communicate, synchronize, and perform tasks on behalf of each other. This provides Cypress the ability to respond to the application's events in real time, and at the same time work outside of the browser for tasks that require a higher privilege.
Prerequisites
Expand |
---|
For this example we will use Cypress to write tests that aim to validate the Cypress todo example. We will need:
|
To start using the Cypress please follow the Get Started documentation.
The tests consists in validating the operations over todo's elements of the Cypress todo example, for that we have defined several tests to:
- Validate that we can add new todo items;
- Validate that we can check an item as completed;
- Validate that we can filter for completed/uncompleted tasks;
- Validate that we can delete all completed tasks.
This The target web application is a simple application with the following aspect "todos" made available by Cypress.
Each of these tests will have a series of actions and validations to check that the desired behavior is happening as we can see below:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
describe('example to-do app', () => { beforeEach(() => { cy.visit(Cypress.config('https://example.cypress.io/todo'baseUrl')) }) it('can add new todo items', () => { const newItem = 'Feed the cat' cy.get('[data-test=new-todo]').type(`${newItem}{enter}`) cy.get('.todo-list li') .should('have.length', 3) .last() .should('have.text', newItem) }) it('can check an item as completed', () => { cy.contains('Pay electric bill') .parent() .find('input[type=checkbox]') .check() cy.contains('Pay electric bill') .parents('li') .should('have.class', 'completed') }) context('with a checked task', () => { beforeEach(() => { cy.contains('Pay electric bill') .parent() .find('input[type=checkbox]') .check() }) it('can filter for uncompleted tasks', () => { cy.contains('Active').click() cy.get('.todo-list li') .should('have.length', 1) .first() .should('have.text', 'Walk the dog') cy.contains('Pay electric bill').should('not.exist') }) it('can filter for completed tasks', () => { cy.contains('Completed').click() cy.get('.todo-list li') .should('have.length', 1) .first() .should('have.text', 'Pay electric bill') cy.contains('Walk the dog').should('not.exist') }) it('can delete all completed tasks', () => { cy.contains('Clear completed').click() cy.get('.todo-list li') .should('have.length', 1) .should('not.have.text', 'Pay electric bill') cy.contains('Clear completed').should('not.exist') }) }) }) |
The tests are simple but let's look into two diferences that allow a little more control, the first one is the possibility to use hooks like beforeEach
to, as the name implies, execute some operations before each test execution. In this example we are accessing the target page before each test avoiding repeating this instruction in each test.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
... beforeEach(() => { cy.visit('https://example.cypress.io/todo') }) ... |
The other one helps in the test organization and have a direct effect on how the results will be written in the result file, in our case we are using context
(but we could use describe
or specify
). This will group the tests beneath into the same testsuite.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
... context('with a checked task', () => { ... |
These tests are defined to validate the application ability to manage todo's by accessing the Cypress todo example and performing operations that will generate an expected output.
Once the code is implemented it can be executed with the following command:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
npx cypress run |
The results are immediately available in the terminal terminal.
In this example, all tests have succeed, the output generated to the terminal is the above one and the correspondent JUnit report is as below:as seen in the previous terminal screenshot. It generates the following JUnit XML report.
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<?xml version="1.0" encoding="UTF-8"?> <testsuites name="Mocha Tests" time="4.404" tests="6" failures="0"> <testsuite name="Root Suite" timestamp="2023-01-30T17:46:57" tests="0" file="cypress/e2e/todo.cy.js" time="0.000" failures="0"> </testsuite> <testsuite name="example to-do app" timestamp="2023-01-30T17:46:57" tests="3" time="0.000" failures="0"> <testcase name="example to-do app displays two todo items by default" time="0.842" classname="displays two todo items by default"> </testcase> <testcase name="example to-do app can add new todo items" time="0.477" classname="can add new todo items"> </testcase> <testcase name="example to-do app can check off an item as completed" time="0.267" classname="can check off an item as completed"> </testcase> </testsuite> <testsuite name="with a checked task" timestamp="2023-01-30T17:47:00" tests="3" time="1.060" failures="0"> <testcase name="example to-do app with a checked task can filter for uncompleted tasks" time="0.345" classname="can filter for uncompleted tasks"> </testcase> <testcase name="example to-do app with a checked task can filter for completed tasks" time="0.350" classname="can filter for completed tasks"> </testcase> <testcase name="example to-do app with a checked task can delete all completed tasks" time="0.341" classname="can delete all completed tasks"> </testcase> </testsuite> </testsuites> |
Notes:
- You can invoke Cypress locally and use it to assist you to write and execute tests with:
npx cypress open
- Use
cypress.config.js
to define configuration values such as taking screenshots, recordings or the reporter to use (more info here). - Different parameters can be used in the command line (more info here)
- We are using JUnit reporter but others are available (more info here)
Integrating with Xray
As we saw in the above previous example, where we are producing JUnit reports with the result of the tests, it test results. It is now a matter of importing those results to your Jira instance, ; this can be done by simply submitting automation results to Xray through the REST API, by using one of the available CI/CD plugins (e.g. for Jenkins), or using the Jira interface to do so.
UI Tabs | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Tips
- after results are imported, in Jira Tests can be linked to existing requirements/user stories, so you can track the impacts on their coverage.
- results from multiple builds can be linked to an existing Test Plan, to facilitate the analysis of test result trends across builds.
- results can be associated with a Test Environment, in case you want to analyze coverage and test results by that environment later on. A Test Environment can be a testing stage (e.g. dev, staging, preprod, prod) or a identifier of the device/application used to interact with the system (e.g. browser, mobile OS).
References
Table of Contents | ||
---|---|---|
|
CSS Stylesheet |
---|
.toc-btf { position: fixed; } |