DEV Community: Viktorija Filipov

Cypress Workshop Part 11: Reporting - Qase, Github Actions

Viktorija Filipov — Sun, 02 Jul 2023 20:06:40 +0000

Qase

Qase is a test management tool, used for test documentation, test execution, reporting etc. In this tutorial, you will learn how to connect your test run in Cypress and push results to Qase. This will serve to have one report for manual and for automated testing.

Steps:

Go to Qase website and create account: Qase
Once you do it create a new project called for example Cypress Workshop - Book Store

Inside the project create a new test suite and call it Web for example.
Inside the web suite, create and document all test cases we have automated for book store app. Fill them with all details and steps. Create one additional test case for example for registration, that is NOT part of our automation suite, we want to execute it manually but still needs to be documented here.

Create a new test plan and call it Web Regression for example. Include all our test cases there.

Go to test runs and create a new test run that includes all test cases from the test plan. Start a test run.

Go to project settings → setting and check these two points to allow bulk push of cypress results

Go to api tokens page and create a new token. Save token value somewhere we will need it later.

Go to your cypress project and execute in terminal these 3 commands to install dependencies for Qase:

npm install cypress-qase-reporter

npm install dotenv

npm install prompt

Under root directory of the project create new folder scripts and new file cypress-with-qase.js
Write the following code inside to manage a test run with case (upon each run prompt will ask for Qase specific values of project and run, and it will also ask for which automation suite you want to run. We are also providing basic Cypress config)

require('dotenv').config();
const prompt = require('prompt');
const cypress = require('cypress');

prompt.start();
prompt.get(
    [
        {
            name: 'PROJECT_ID',
            description: 'Provide Qase PROJECT_ID',
            type: 'string',
            required: true,
        },
        {
            name: 'RUN_ID',
            description: 'Provide RUN_ID for the Qase test run',
            type: 'number',
            required: true,
        },
        {
            name: 'SUITE',
            description: 'Provide SUITE folder path for the Qase test run',
            type: 'string',
            required: true,
        },
    ],
    function (err, result) {
        cypress.run({
            spec: `cypress/e2e/${result.SUITE}/*.cy.js`,
            browser: 'chrome',
            reporter: 'cypress-qase-reporter',
            headed: true,
            reporterOptions: {
                apiToken: process.env.QASE_API_KEY,
                projectCode: result.PROJECT_ID,
                runId: result.RUN_ID,
                logging: true,
            },
        });
    }
);

Go to package.json file and add new command for running Cypress with Qase (line 13):

{
  "name": "cypress-workshop",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "cypress-cli-prod": "cypress open --env prod=1",
    "cypress-headed-prod": "cypress run --headed -b chrome --env prod=1",
    "cypress-headless-prod": "cypress run --headless -b chrome --env prod=1",
    "cypress-cli-staging": "cypress open",
    "cypress-headed-staging": "cypress run --headed -b chrome",
    "cypress-headless-staging": "cypress run --headless -b chrome",
    "cypress:run:qase": "QASE_REPORT=1 node scripts/cypress-with-qase.js",
    "eslint": "eslint cypress",
    "eslint-fix": "eslint cypress --fix"
  },
  "author": "",
  "license": "ISC",
  "husky": {
    "hooks": {
      "pre-commit": "npm run eslint-fix"
    }
  },
  "devDependencies": {
    "cypress": "^10.0.0",
    "eslint": "^8.16.0",
    "eslint-config-airbnb": "^19.0.4",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-chai-friendly": "^0.7.2",
    "eslint-plugin-cypress": "^2.12.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-jsx-a11y": "^6.5.1",
    "eslint-plugin-prettier": "^4.0.0",
    "eslint-plugin-react": "^7.30.0",
    "husky": "^8.0.1",
    "prettier": "^2.6.2"
  },
  "dependencies": {
    "cypress-file-upload": "^5.0.8",
    "cypress-qase-reporter": "^1.4.2-alpha.2",
    "dotenv": "^16.0.1",
    "prompt": "^1.3.0"
  }
}

Now, go back to Qase app and find out IDs of each test case. It is a number next to project ID (for example, here CWBS is a project ID and 1 is case ID and so forth):

Go back to your automation project and export API key from Qase we received before. This is how you should write it and execute in terminal, but YOUR KEY IS DIFFERENT, PASTE YOUR KEY from step 8 here:

export QASE_API_KEY=46b7d640b6841da28aea575cb6084141661976bcq

Edit each test case to include your IDs from Qase, we are matching documentation with automation here:

addBookToProfile.cy.js:

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Add Book To Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  qase(
    1,
    it('Check adding book to profile collection', () => {
      // Navigate to book store
      navigateTo.bookStore();
      // Load books fixture
      cy.fixture('books').then((books) => {
        // Add first books to collection
        bookActions.addBookToCollection(books.collection1.Git);
        // Handle alert and verify alert message
        cy.verifyWindowAlertText(`Book added to your collection.`);
        // Navigate to user profile and verify that book is in collection table
        navigateTo.profile();
        cy.get('.rt-tbody').find('.rt-tr-group').first().should('contain', books.collection1.Git);
      });
    })
  );
});

checkBookInfo.cy.js:

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Check Book Info', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Add book to book collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStore();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.DesignPatternsJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  qase(
    2,
    it('Check book info from profile table', () => {
      // Navigate to user profile
      navigateTo.profile();
      // Load books fixture
      cy.fixture('books').then((books) => {
        // Click on book in collection to open book info
        profileActions.checkBookData(books.collection1.DesignPatternsJS);
      });
      // Define book info elements
      const bookDataElements = [
        '#ISBN-label',
        '#title-label',
        '#subtitle-label',
        '#author-label',
        '#publisher-label',
        '#pages-label',
        '#description-label',
        '#website-label',
      ];
      // Check book info elements
      cy.elementVisible(bookDataElements);
      // Define data about the book
      const bookData = [
        '9781449331818',
        'Learning JavaScript Design Patterns',
        `A JavaScript and jQuery Developer's Guide`,
        'Addy Osmani',
        `O'Reilly Media`,
        '254',
      ];
      // Check data about the book
      cy.textExists(bookData);
    })
  );
});

deleteBookFromProfile.cy.js:

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Delete Book From Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Add book to collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStore();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.SpeakingJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  qase(
    3,
    it('Check deleting book from profile collection - confirm deletion', () => {
      cy.fixture('books').then((books) => {
        // Navigate to user profile
        navigateTo.profile();
        // Check if book is in the collection table
        cy.get('.rt-tbody')
          .find('.rt-tr-group')
          .first()
          .should('contain', books.collection1.SpeakingJS);
        // Delete book from table - confirm deletion
        profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'ok');
        // Handle delete alert and verify message
        cy.verifyWindowAlertText(`Book deleted.`);
        // Verify that book is no longer in collection table and that table is empty
        cy.get('.rt-tbody').should('not.contain', books.collection1.SpeakingJS);
        cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
      });
    })
  );

  qase(
    6,
    it('Check deleting book from profile collection - decline deletion', () => {
      cy.fixture('books').then((books) => {
        // Navigate to user profile
        navigateTo.profile();
        // Check if book is in the collection table
        cy.get('.rt-tbody')
          .find('.rt-tr-group')
          .first()
          .should('contain', books.collection1.SpeakingJS);
        // Cancel book deletion
        profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'cancel');
        // Verify that book is still in the table
        cy.get('.rt-tbody').should('contain', books.collection1.SpeakingJS);
      });
    })
  );
});

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Login user', () => {
  // Navigate to login page
  beforeEach('Navigate to Login page', () => {
    navigateTo.login();
  });
  qase(
    7,
    it('Check valid user credentials', () => {
      // Load users fixture
      cy.fixture('users').then((users) => {
        // Perform login
        auth.login(users.user2.username, users.user2.password);
      });
      // Verify that user is redirected to profile page (user is logged in)
      cy.url().should('contain', Cypress.env('profile'));
    })
  );

  qase(
    8,
    it('Check invalid user credentials', () => {
      // Perform login
      auth.login('invalid345', 'invalid345');
      // Verify that user is still on login page (user is not logged in)
      cy.url().should('contain', Cypress.env('login'));
      // Verify that error message is displayed
      cy.get('#output').should('contain', 'Invalid username or password!');
    })
  );

  qase(
    9,
    it('Check login with invalid username and valid password', () => {
      // Load users fixture
      cy.fixture('users').then((users) => {
        // Perform login
        auth.login('invalid345', users.user2.password);
      });
      // Verify that user is still on login page (user is not logged in)
      cy.url().should('contain', Cypress.env('login'));
      // Verify that error message is displayed
      cy.get('#output').should('contain', 'Invalid username or password!');
    })
  );

  qase(
    10,
    it('Check login with valid username and invalid password', () => {
      // Load users fixture
      cy.fixture('users').then((users) => {
        // Perform login
        auth.login(users.user2.username, 'invalid345');
      });
      // Verify that user is still on login page (user is not logged in)
      cy.url().should('contain', Cypress.env('login'));
      // Verify that error message is displayed
      cy.get('#output').should('contain', 'Invalid username or password!');
    })
  );
});

logout.cy.js:

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Log out user', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  qase(
    11,
    it('Check logging out user', () => {
      // Navigate to user profile
      navigateTo.profile();
      // Perform log out
      auth.logout();
      // Assert that user is on login page
      cy.url().should('contain', Cypress.env('login'));
    })
  );
});

searchBookstore.cy.js:

/// <reference types="Cypress" />

import { qase } from 'cypress-qase-reporter/dist/mocha';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Bookstore: Search For Book', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  qase(
    12,
    it('Check searching for existing book in book store', () => {
      // Navigate to bookstore
      navigateTo.bookStore();
      // Load books fixture
      cy.fixture('books').then((books) => {
        // Perform book search
        bookActions.searchCollection(books.collection1.DesignPatternsJS);
        // Verify that there is a book in filtered table (in search result)
        cy.get('.rt-tbody')
          .find('.rt-tr-group')
          .first()
          .should('contain', books.collection1.DesignPatternsJS);
      });
    })
  );

  qase(
    13,
    it('Check searching for non-existing book in book store', () => {
      // Define invalid book name
      const invalid_book_name = 'Game of Thrones';
      // Navigate to bookstore
      navigateTo.bookStore();
      // Perform book search
      bookActions.searchCollection(invalid_book_name);
      // Assert that there are no search results (no book in the table and table is empty)
      cy.get('.rt-tbody').should('not.contain', invalid_book_name);
      cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
    })
  );
});

Finally let’s run the tests. In your terminal write execute command

npm run cypress:run:qase

and answer questions, provide project ID, run ID and suite you want to run, in this case bookstore suite.

You can find run ID only in URL as last number when you navigate to your test run page:

Once the test run is completed, you will be able to see results in terminal and also in Qase app just refresh test run page in Qase.

As you can see all test cases results are uploaded from Cypress to Qase. We have only one manual test case left to be executed and you can execute it manually in Qase itself. That we we combined automated and manual test execution.

Github Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

ℹ️ Learn more about Github Actions: Github Actions

ℹ️ Github Actions + Cypress: GA and Cypress

You can customize your CI/CD pipelines according to your project needs. In this demo we will create an example github actions which will allow us to do few simple actions:

Schedule cron job to run cypress tests at 10am UTC every Sunday
Run cypress tests on each push to main branch

Cypress test run job will consist of following:

Defining container and machine where tests will run
Installing dependencies
Running all our tests in default headless mode on Chrom

So, how do we write this?

Create a new folder .github in the root directory.
Create a new folder workflows , under .github
Create a new file main.yml

Write following content inside (best to copy paste because this file is sensitive to spaces etc.):

name: Cypress Tests

on:
  schedule:
  #schedule at 10:00 on Sunday
  - cron: '0 10 * * sun'
  push:
    branches:
      - main
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    container: cypress/browsers:node12.18.3-chrome87-ff82
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install    

      - name: 'Run all tests'
        uses: cypress-io/github-action@v4
        with:
          # we have already installed all dependencies above
          install: false
          wait-on: 'https://demoqa.com'
          wait-on-timeout: 120
          browser: chrome
          spec: cypress/e2e/**/*

Once you push this file to your remote github repository, github will immediately start a test run. You can see it in my cypress presentation repo that contains all work from previous lessons: link

You can see your test runs github performed under actions. When you open certain flow you will see its log and all of the output of the test run.

Above is the example of the scheduled run I set up to start each Sunday at 10am UTC.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: qase and github actions support"

git push

Thank you for following this workshop. I hope it was useful. For any questions, you know where to find me: My LinkedIn

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 10: API, Working on different environments

Viktorija Filipov — Sun, 02 Jul 2023 19:42:07 +0000

Working on different environments

In real-life project, you will often have to test applications on different environments, not just one. Usually that environment won’t be production, but some sort of test environment.

For our Demo QA application, we unfortunately don’t have a test environment, but I will show you how you can write the code same as if you had tested one.

Firstly, with Cypress 10, you can manage your environments in different ways: through full definition in cypress.config.json file, or you can define it in different config files and then call it in the main one. Since we don’t have a large configuration data here, I will show you the simple way or storing environment info only in cypress.config.json. With that in mind, let’s edit that file and write this code in:

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  defaultCommandTimeout: 5000,
  video: false,
  screenshotOnRunFailure: false,
  chromeWebSecurity: false,
  retries: 0,
  viewportWidth: 1920,
  viewportHeight: 1080,
  e2e: {
    setupNodeEvents(on, config) {
      if (config.env.prod) {
        return {
          baseUrl: "https://demoqa.com",
          env: {
            env: "prod",
            apiUrl: "https://demoqa.com",
            apiGenerateToken: "/Account/v1/GenerateToken",
            apiLogin: "/Account/v1/Login",
            apiAuthorized: "/Account/v1/Authorized",
            apiUser: "/Account/v1/User",
            login: "/login",
            profile: "/profile",
            books: "/books"
          },
        };
      } else
      return {
        //Change these values with values from another environment
        baseUrl: "https://demoqa.com",
        env: {
          env: "staging",
          apiUrl: "https://demoqa.com",
          apiGenerateToken: "/Account/v1/GenerateToken",
          apiLogin: "/Account/v1/Login",
          apiAuthorized: "/Account/v1/Authorized",
          apiUser: "/Account/v1/User",
          login: "/login",
          profile: "/profile",
          books: "/books"
        },
      };
    },
  },
});

Code explanation

Line 11 is where environment configuration begins
Lines 12 to 27: we are defining what will happen if we run tests in production environment. Meaning, which baseUrl will be used, how we will name that environment, which environment variables will be used (URL extensions etc.)
Lines 28-46: Here it is defined what will be used in any other case, meaning in for example staging environment. Notice I used same baseUrl and env variables because we don’t actually have staging environment, this is just to show you how to write it for different environments.
All the extensions for URLs/pages will be later used in tests or to call some API method, so you will see later how it is being called in the test.

Next, in order for Cypress to know on which environment it should run the tests, we need to edit commands in package.json file and provide env variable names pointing to certain environment, in this case - production. So let’s edit that file as well to look like this:

{
  "name": "cypress-workshop",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "cypress-cli-prod": "cypress open --env prod=1",
    "cypress-headed-prod": "cypress run --headed -b chrome --env prod=1",
    "cypress-headless-prod": "cypress run --headless -b chrome --env prod=1",
    "cypress-cli-staging": "cypress open",
    "cypress-headed-staging": "cypress run --headed -b chrome",
    "cypress-headless-staging": "cypress run --headless -b chrome",
    "eslint": "eslint cypress",
    "eslint-fix": "eslint cypress --fix"
  },
  "author": "",
  "license": "ISC",
  "husky": {
    "hooks": {
      "pre-commit": "npm run eslint-fix"
    }
  },
  "devDependencies": {
    "cypress": "^10.0.0",
    "eslint": "^8.16.0",
    "eslint-config-airbnb": "^19.0.4",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-chai-friendly": "^0.7.2",
    "eslint-plugin-cypress": "^2.12.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-jsx-a11y": "^6.5.1",
    "eslint-plugin-prettier": "^4.0.0",
    "eslint-plugin-react": "^7.30.0",
    "husky": "^8.0.1",
    "prettier": "^2.6.2"
  },
  "dependencies": {
    "cypress-file-upload": "^5.0.8"
  }
}

Code explanation

We added more commands with the order to Cypress to run production configuration (Lines 7-9).
If we run commands on lines 10,11,12 - Cypress will run default environment - in this case also production since we don’t have others.

Next, since we have predefined URLs in the config file we can refactor navigation.js Bookstore page object file and call those environment variables in appropriate places, instead of hard-coding them.

export class NavigateTo {
  login() {
    cy.visit(Cypress.env('login'));
  }

  profile() {
    cy.visit(Cypress.env('profile'));
  }

  bookStore() {
    cy.visit(Cypress.env('books'));
  }
}

export const navigateTo = new NavigateTo();

Code explanation

Refactored lines - 3,7,11 - we replaced hard-coded values with definition of URL extensions from environment variables, so Cypress will read these values from cypress.config.js file.

Before we jump to the next part of the lesson, let’s add one file called utils.js under support folder. Util files are being used to store some very generic “mini” functions that are helpful to perform some operations in other parts of the project. In this case, we will put one function in utils.js, that will - once called - generate a few random numbers. This will be useful later to create random usernames for our users.

export const randomFiveNumbers = () =>
  (Math.floor(Math.random() * 100000) + 100000).toString().substring(1);

ℹ️ Learn more about environment variables in Cypress: env vars

API methods as helpers or shortcuts in UI testing

Since this workshop is not about backend development or testing, we will not go too into learning API. We just need to know what it stands for and how we can use it for now.

API stands for Application Programming Interface. In the context of APIs, the word Application refers to any software with a distinct function. Interface can be thought of as a contract of service between two applications. This contract defines how the two communicate with each other using requests and responses. Their API documentation contains information on how developers are to structure those requests and responses.

A REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer.

ℹ️ Read more about API testing and Postman software: api testing

In very simple terms: API is a layer of software below UI level. It is part of backend architecture. Why are we interested in it? Because, even though we are learning here web UI automation testing, we still want to use API layer to speed up things. For example - actions defined in preconditions and postconditions of the tests. There is no need to do them through UI, since they are not really our core test or test subject. We can achieve the same result calling APIs that will do the same operation as if we were using UI. For example, login user. Can be done in 10 seconds via UI or 1 second via API in our case. Definitely better to do that precondition as API method and speed up our tests. The core of the test will always be UI interaction for this type of testing automation.

With all that in mind, you can see that our book store app has open API documentation from where we can see API definition and translate that into automated code.

Visit swagger docs

Thought process here is:

Check what kind of actions we performed in preconditions and postconditions
Look in docs above for API that can do the same thing
If doc is unclear, perform the action manually with opened web developer tools and network tab and see which APIs are triggered.

Example: I just performed login and saw which API and with which parameters was fired

Test API manually in Postman to figure out how it works
Write api script in cypress

Note: It will not always be this simple, like fire one API and it resolves all your problems. For this login action, it won’t. From experience, I know that app is keeping tokens, session data, cookies and things like that, so I look for those APIs in docs and I figured out way how to automate login fully. I can’t explain this thought process in detail since it is mostly experience based, but if you are stuck with defining API actions DO ASK A BACKEND DEVELOPER on the project, and they will explain exactly which API with which parameters and in which order you should hit, in order to perform some action.

For the purposes of this demo I will refactor preconditions with API related to user creation, login, and I also added postcondition to delete user after every test.

So, let’s create api folder under support folder. Under api folder, create auth.js file, since all our API definitions are related to authentication for now. Write this code:

export const generateToken = (username, password) =>
  cy
    .request({
      method: 'POST',
      url: `${Cypress.env('apiUrl')}${Cypress.env('apiGenerateToken')}`,
      body: {
        userName: username,
        password,
      },
    })
    .then((response) => {
      cy.setCookie('token', response.body.token);
      cy.setCookie('expires', response.body.expires);
    });

export const createUser = (username, password) =>
  cy
    .request({
      method: 'POST',
      url: `${Cypress.env('apiUrl')}${Cypress.env('apiUser')}`,
      body: {
        userName: username,
        password,
      },
    })
    .then((response) => {
      cy.setCookie('userID', response.body.userID);
      cy.setCookie('UserName', response.body.username);
    });

export const deleteUser = (username, password) => {
  cy.request({
    method: 'POST',
    url: `${Cypress.env('apiUrl')}${Cypress.env('apiLogin')}`,
    body: {
      userName: username,
      password,
    },
  }).then((response) => {
    cy.request({
      method: 'DELETE',
      headers: {
        authorization: `Bearer ${response.body.token}`,
      },
      url: `${Cypress.env('apiUrl')}${Cypress.env('apiUser')}/${response.body.userId}`,
    });
  });
};

Code explanation:

You can see 3 functions generateToken, createUser, deleteUser.
Each of these functions will call certain API methods to perform desired action.
generateToken function is calling API to generate user token so that user stays logged in
createUser function is calling API to create new user
deleteUser function is calling two APIs, first it is calling login API to get response with user id, and then it is calling delete user API method using that id to refer to which user to delete.
In generateToken and createUser we are storing cookies that will let Cypress know that user is logged in and keep it that way.

Note: don’t stress if you don’t understand API code here or you didn’t work with APIs, some basic API knowledge is a precondition to understand this. Just try to learn more about how API works and what it is for and ask backend developers for help on project you are working on if you want to do things like this. Every project is different, every architecture is different and API definitions are different on all applications.

ℹ️ Learn more about Cypress request method: request

In order to use these functions more naturally and easily, we can add them to our custom commands and create custom commands for them. So add 3 custom commands to commands.js file to look like this:

// ***********************************************
// This example commands.js shows you how to
// create various custom commands and overwrite
// existing commands.
//
// For more comprehensive examples of custom
// commands please read more here:
// https://on.cypress.io/custom-commands
// ***********************************************
//
//
// -- This is a parent command --
// Cypress.Commands.add('login', (email, password) => { ... })
//
//
// -- This is a child command --
// Cypress.Commands.add('drag', { prevSubject: 'element'}, (subject, options) => { ... })
//
//
// -- This is a dual command --
// Cypress.Commands.add('dismiss', { prevSubject: 'optional'}, (subject, options) => { ... })
//
//
// -- This will overwrite an existing command --
// Cypress.Commands.overwrite('visit', (originalFn, url, options) => { ... })
import 'cypress-file-upload';
import * as api from './api/auth';
import * as utils from './utils';

const username = `user${utils.randomFiveNumbers()}`;
const password = 'Test123456!';

Cypress.Commands.add('verifyWindowAlertText', (alertText) => {
  cy.once('window:alert', (str) => {
    expect(str).to.equal(alertText);
  });
});

Cypress.Commands.add('elementVisible', (locator) => {
  cy.wrap(locator).each((index) => {
    cy.get(index).then((el) => {
      cy.get(el).should('be.visible');
    });
  });
});

Cypress.Commands.add('textExists', (text) => {
  cy.wrap(text).each((index) => {
    cy.contains(index).should('exist');
  });
});

Cypress.Commands.add('createUser', () => {
  api.createUser(username, password);
});

Cypress.Commands.add('generateToken', () => {
  api.generateToken(username, password);
});

Cypress.Commands.add('deleteUser', () => {
  api.deleteUser(username, password);
});

Code explanation:

We added 3 commands to call our already defined API methods. (lines 53-63)
on lines 31 and 32 we defined how our username and password should look like. For username, in order to be unique we are always generating new one with different combination or letters and numbers (calling function from utils to generate random number combination)

Now that we have everything in place we can finally …

…REFACTOR OUR EXISTING TESTS…

Refactoring: addBookToProfile.cy.js

/// <reference types="Cypress" />

import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Add Book To Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  it('Check adding book to profile collection', () => {
    // Navigate to book store
    navigateTo.bookStore();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Add first books to collection
      bookActions.addBookToCollection(books.collection1.Git);
      // Handle alert and verify alert message
      cy.verifyWindowAlertText(`Book added to your collection.`);
      // Navigate to user profile and verify that book is in collection table
      navigateTo.profile();
      cy.get('.rt-tbody').find('.rt-tr-group').first().should('contain', books.collection1.Git);
    });
  });
});

Code explanation:

We refactored:

Precondition - to create user and login via API
Edited postcondition - delete user via API (no need to delete book, we can just delete this user all together)
Navigation name to navigate to bookstore

Refactoring checkBookInfo.cy.js:

/// <reference types="Cypress" />

import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Check Book Info', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Add book to book collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStore();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.DesignPatternsJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  it('Check book info from profile table', () => {
    // Navigate to user profile
    navigateTo.profile();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Click on book in collection to open book info
      profileActions.checkBookData(books.collection1.DesignPatternsJS);
    });
    // Define book info elements
    const bookDataElements = [
      '#ISBN-label',
      '#title-label',
      '#subtitle-label',
      '#author-label',
      '#publisher-label',
      '#pages-label',
      '#description-label',
      '#website-label',
    ];
    // Check book info elements
    cy.elementVisible(bookDataElements);
    // Define data about the book
    const bookData = [
      '9781449331818',
      'Learning JavaScript Design Patterns',
      `A JavaScript and jQuery Developer's Guide`,
      'Addy Osmani',
      `O'Reilly Media`,
      '254',
    ];
    // Check data about the book
    cy.textExists(bookData);
  });
});

Code explanation:

We refactored:

Precondition - to create user and login via API
Edited postcondition - delete user via API(no need to delete book, we can just delete this user all together)
Navigation name to navigate to bookstore

*Refactoring deleteBookFromProfile.cy.js: *

/// <reference types="Cypress" />

import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Delete Book From Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Add book to collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStore();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.SpeakingJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  it('Check deleting book from profile collection - confirm deletion', () => {
    cy.fixture('books').then((books) => {
      // Navigate to user profile
      navigateTo.profile();
      // Check if book is in the collection table
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.SpeakingJS);
      // Delete book from table - confirm deletion
      profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'ok');
      // Handle delete alert and verify message
      cy.verifyWindowAlertText(`Book deleted.`);
      // Verify that book is no longer in collection table and that table is empty
      cy.get('.rt-tbody').should('not.contain', books.collection1.SpeakingJS);
      cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
    });
  });

  it('Check deleting book from profile collection - decline deletion', () => {
    cy.fixture('books').then((books) => {
      // Navigate to user profile
      navigateTo.profile();
      // Check if book is in the collection table
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.SpeakingJS);
      // Cancel book deletion
      profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'cancel');
      // Verify that book is still in the table
      cy.get('.rt-tbody').should('contain', books.collection1.SpeakingJS);
    });
  });
});

Code explanation:

We refactored:

Precondition - to create user and login via API
Edited postcondition - delete user via API (no need to delete book, we can just delete this user all together)
Navigation name to navigate to bookstore

Refactoring login.cy.js:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Login user', () => {
  // Navigate to login page
  beforeEach('Navigate to Login page', () => {
    navigateTo.login();
  });

  it('Check valid user credentials', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login(users.user2.username, users.user2.password);
    });
    // Verify that user is redirected to profile page (user is logged in)
    cy.url().should('contain', Cypress.env('profile'));
  });

  it('Check invalid user credentials', () => {
    // Perform login
    auth.login('invalid345', 'invalid345');
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', Cypress.env('login'));
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });

  it('Check login with invalid username and valid password', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login('invalid345', users.user2.password);
    });
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', Cypress.env('login'));
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });

  it('Check login with valid username and invalid password', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login(users.user2.username, 'invalid345');
    });
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', Cypress.env('login'));
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });
});

Code explanation:

We refactored:

URL assertions not to be hardcoded but to read values from environment variables from cypress.config.js file

Refactoring logout.cy.js:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Log out user', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  it('Check logging out user', () => {
    // Navigate to user profile
    navigateTo.profile();
    // Perform log out
    auth.logout();
    // Assert that user is on login page
    cy.url().should('contain', Cypress.env('login'));
  });
});

Code explanation:

We refactored:

Precondition - to create user and login via API
Edited postcondition - delete user via API
URL assertion to refer to env variables

Refactoring searchBookstore.cy.js:

/// <reference types="Cypress" />

import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Bookstore: Search For Book', () => {
  // Perform login
  beforeEach('Perform login', () => {
    cy.createUser();
    cy.generateToken();
  });

  // Delete user
  afterEach('Delete user', () => {
    cy.deleteUser();
  });

  it('Check searching for existing book in book store', () => {
    // Navigate to bookstore
    navigateTo.bookStore();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Perform book search
      bookActions.searchCollection(books.collection1.DesignPatternsJS);
      // Verify that there is a book in filtered table (in search result)
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.DesignPatternsJS);
    });
  });

  it('Check searching for non-existing book in book store', () => {
    // Define invalid book name
    const invalid_book_name = 'Game of Thrones';
    // Navigate to bookstore
    navigateTo.bookStore();
    // Perform book search
    bookActions.searchCollection(invalid_book_name);
    // Assert that there are no search results (no book in the table and table is empty)
    cy.get('.rt-tbody').should('not.contain', invalid_book_name);
    cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
  });
});

Code explanation:

We refactored:

Precondition - to create user and login via API
Added postcondition - delete user via API
Bookstore navigation

HOMEWORK:

Refactor preconditions/postconditions to be fully with API not UI. Figure out how to add/delete book through API. Use swagger docs as reference.
Learn more about APIs
Read info sections

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: api refactoring, env variables"

git push

SEE YOU IN LESSON 11!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 9: Reusability, Page Object Pattern, Commands

Viktorija Filipov — Sat, 17 Jun 2023 20:07:20 +0000

Updates

Before we begin with this lesson, let’s do some updates for our code:

1: In package.json file, edit run command for headed run to be:

"cypress-headed": "cypress run --headed -b chrome"

The reason for this is adding a headed flag, so we can see test execution UI when we run this terminal command.

2: Add new fixture file books.json in fixtures containing all the books in bookstore app:

{
    "collection1": {
        "Git": "Git Pocket Guide",
        "DesignPatternsJS": "Learning JavaScript Design Patterns",
        "API": "Designing Evolvable Web APIs with ASP.NET",
        "SpeakingJS": "Speaking JavaScript",
        "Don'tKnowJS": "You Don't Know JS",
        "JSApps": "Programming JavaScript Applications",
        "JSSecond": "Eloquent JavaScript, Second Edition",
        "ECMA": "Understanding ECMAScript 6"
    }
}

3: I have created one user for bookstore app we will use for login for today’s lesson, so let’s add that second user login info to our users.json fixture. The final users.json fixture should now look like:

{
  "user1": {
    "firstName": "Harvey",
    "lastName": "Specter",
    "age": "40",
    "userEmail": "specter@example.com",
    "salary": "700000",
    "department": "legal"
  },
  "user2": {
    "username": "repartner",
    "password": "Test123456!"
  }
}

Commands

Ok, so let’s first start with commands in Cypress. What are commands?

Cypress custom commands are described by users and not the default commands from Cypress. These customized commands are used to create the test steps that are repeated in an automation flow.

We can add and overwrite an already pre-existing command. They should be placed in the commands.js file within the support folder present in the Cypress project.

So, essentially, this Cypress feature allows us to create customized Cypress commands for reusable pieces of code. We want to write custom commands for all functions that are globally repeating throughout the project.

For now, I came up with three custom commands we can write and use everywhere in our tests, so those are global, general commands to handle some actions we will repeat in few places but are not strictly related to any particular page in our app.

ℹ️ Learn more about Cypress custom commands: commands

1: Open commands.js file and add these 3 commands to it:

Cypress.Commands.add('verifyWindowAlertText', (alertText) => {
  cy.once('window:alert', (str) => {
    expect(str).to.equal(alertText);
  });
});

Cypress.Commands.add('elementVisible', (locator) => {
  cy.wrap(locator).each((index) => {
    cy.get(index).then((el) => {
      cy.get(el).should('be.visible');
    });
  });
});

Cypress.Commands.add('textExists', (text) => {
  cy.wrap(text).each((index) => {
    cy.contains(index).should('exist');
  });
});

Code explanation:

verifyWindowAlertText command will help us to verify alert text on some page. If it is called in the test, it will be executed once for a single alert. If we want to verify some other alert within the same test, we will call it again.

elementVisible command will help us asset existence of multiple elements so that we don’t have to write assertion code for each element separately. We will just provide an array of elements and call this command to check them all.

textExists similarly to the previous command, this one will assert that an array of text exist on the page.

Page Object Pattern

Page Object Model is a design pattern in the automation world which has been famous for its test maintenance approach and avoiding code duplication. A page object is a class that represents a page in the web application. Under this model, the overall web application breaks down into logical pages. Each page of the web application generally corresponds to one class in the page object, but can even map to multiple classes also, depending on the classification of the pages. This Page class will contain all the locators of the Web Elements of that web page and will also contain methods that can perform operations on those Web Elements.

What are the benefits of using Page Object Pattern?

As we have seen that the Page Object Pattern provides flexibility to writing code by splitting into different classes and also keeps the test scripts separate from the locators. Considering this, few of the important benefits of the Page Object Model are:

Code reusability – The same page class can be used in different tests, and all the locators and their methods can be re-used across various test cases.
Code maintainability – There is a clean separation between test code which can be our functional scenarios and page-specific code such as locators and methods. So, if some structural change happens on the web page, it will just impact the page object and will not have any impacts on the test scripts.

💡 From personal experience on enterprise projects, there is one advice I can give you - Sometimes you will have to test pages of web applications that are very complex, have multiple large features and require a massive amount of test cases. In this case, you would NOT create only one page object class to store all page objects and methods for that page. What you will do to make code more maintainable is to separate page object classes by components (features) and not by entire page full of complex features. That is also a valid strategy, used mostly in enterprise projects.

👉 Fun fact: this is also how developers structure their code, usually with components (frontend) or microservices (backend). This means breaking down an enterprise app into smaller projects with large amount of smaller features/components/services etc.

So, let’s get our hands dirty and see how we can implement this strategy in our demo app.

We will use Book Store app within our Demoqa app. You can find it here:

In this Book Store App, we have login/registration page, book store page where you can find all books, and profile page where you can see your personal collection and do a log out.

So, in real life, before you start doing any automation, you first need to come up with test scenarios and write documents for it. For the purposes of this lesson, I came up with a few scenarios:

As you can see above, we have some repetitive steps such as navigating to login page, typing in login form, clicking on login etc. So for those, let’s create two page object classes under support/bookstore_page_objects folders.

1: First one, let’s call it auth.js and let's write there every page object method we need for authentication.

export class Auth {
  login(user_name, password) {
    cy.get('#userName').type(user_name);
    cy.get('#password').type(password);
    cy.get('#login').click();
  }
}

export const auth = new Auth();

Code explanation:

We have created a class Auth to store all page objects/methods related to login, registration etc. and we exported that class into one constant, so we can use it in other tests.

Inside the class we have created one function login that is storing our log in steps, so we can just call this function later in the test, without having to write all these elements and actions inside the test itself. login function is taking to parameters, username and password.

2: Second page object file, it can be about navigation to different pages. This is an example of that “component” mentality, where sometimes you will just create a page object logically, not strictly related to a certain page. Let’s name it navigation.js and write the following code inside:

export class NavigateTo {
  login() {
    cy.visit('/login');
  }
}

export const navigateTo = new NavigateTo();

Code explanation:

We have created a class NavigateTo to store all navigation actions in one place. For this first set of login test cases, we need only one function that will navigate us to the login page.

Now that we have our auth and navigation page object files, and we also have existing user we can use from fixtures we added before (see the top of this lesson), let’s write above tests and translate them into automated code.

3: Create bookstore folder under e2e folder, and create file called login.cy.js. Put the following code inside:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Login user', () => {
  // Navigate to login page
  beforeEach('Navigate to Login page', () => {
    navigateTo.login();
  });

  it('Check valid user credentials', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login(users.user2.username, users.user2.password);
    });
    // Verify that user is redirected to profile page (user is logged in)
    cy.url().should('contain', '/profile');
  });

  it('Check invalid user credentials', () => {
    // Perform login
    auth.login('invalid345', 'invalid345');
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', '/login');
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });

  it('Check login with invalid username and valid password', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login('invalid345', users.user2.password);
    });
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', '/login');
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });

  it('Check login with valid username and invalid password', () => {
    // Load users fixture
    cy.fixture('users').then((users) => {
      // Perform login
      auth.login(users.user2.username, 'invalid345');
    });
    // Verify that user is still on login page (user is not logged in)
    cy.url().should('contain', '/login');
    // Verify that error message is displayed
    cy.get('#output').should('contain', 'Invalid username or password!');
  });
});

Code explanation:

Lines 3-4: In order to use our page objects and methods from them, we need to import them in test file.
Lines 8-10: Before each test we are navigating to login page, by calling “login” function from “navigateTo” page object class constant.
Lines 12-20: We are writing the core of our first case, to login user with valid credentials. In order to use our user credentials, we need to load fixtures file - line: 14. Then, we are calling “auth” page object and method “login” and providing parameters valid user name and valid password from fixtures file. Then, Line 19 we are asserting that user is now on profile page.
Lines 22-57: We are essentially just covering other scenarios where users don’t enter valid credentials in the same way as above described, and we are writing assertions to verify that user is still on login page and error message is displayed.

🚨 VERY IMPORTANT: KEEP YOU ASSERTIONS OUT OF PAGE OBJECT FILES AND ITS METHODS. WRITE ASSERTIONS ONLY IN TEST FILES, AS PRESENTED ABOVE.

So, for this test case you can see that we have some new navigation actions, we also have some actions on book store page and profile page.

Therefore we need to add this actions to existing and new page objects.

1: First, let’s add navigation methods to existing navigation.js page object:

export class NavigateTo {
  login() {
    cy.visit('/login');
  }

  profile() {
    cy.visit('/profile');
  }

  bookStoreFromProfile() {
    cy.get('#gotoStore').click();
  }
}

export const navigateTo = new NavigateTo();

Code explnation:

Line 6: We added new function that will navigate user via URL to profile page.
Line 10: We added new function that will navigate user to bookstore by clicking on button “Go To Book Store”

2: Then, let’s add book_store.js page objects file, to store actions from book store:

export class BookActions {
  addBookToCollection(book_name) {
    cy.contains(book_name).click();
    cy.get('.text-right > #addNewRecordButton').click();
  }
}

export const bookActions = new BookActions();

Code explanation:

Same way we created previous page objects, for this page we are creating a new one with function addBookToCollection that will take a book name as parameter, and will perform action of clicking on the book in the table and clicking on button to add book to collection.

3: Then, we also need page object file related to profile actions such as deleting book from personal collection, so let’s create profile.js file to store its page objects:

export class ProfileActions {
  deleteBookFromTable(book_name, dialog_option) {
    // Find delete button for certain book name and delete book from table
    cy.get('.rt-tbody')
      .contains('.rt-tr-group', book_name)
      .then((row) => {
        cy.wrap(row).find('#delete-record-undefined').click();
        cy.get(`#closeSmallModal-${dialog_option}`).click();
      });
  }
}

export const profileActions = new ProfileActions();

Code explanation:

Same as before, we created new page object class for profile actions, and we created one function deleteBookFromTable that will handle deletion of book from user table in profile (it will search table by book name and in that row it will find “delete” icon and it will click on it. Then, it will click on dialog option to delete/cancel deletion.

As you can see this function takes two parameters we need, and that is book name and also dialog option ('ok'/'cancel') to provide as part of element ID of confirmation dialog. We made it this way to be reusable for delete books tests.

4: Now that we have all page objects and actions in place, we can now write our test case. Create new test case under bookstore folder called addBookToProfile.cy.js and write following code inside:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Add Book To Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    navigateTo.login();
    cy.fixture('users').then((users) => {
      auth.login(users.user2.username, users.user2.password);
    });
  });

  // Delete the book from collection
  afterEach('Delete book from profile collection', () => {
    cy.fixture('books').then((books) => {
      profileActions.deleteBookFromTable(books.collection1.Git, 'ok');
      cy.verifyWindowAlertText(`Book deleted.`);
      cy.get('.rt-tbody').should('not.contain', books.collection1.Git);
      cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
    });
  });

  it('Check adding book to profile collection', () => {
    // Navigate to book store
    navigateTo.bookStoreFromProfile();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Add first books to collection
      bookActions.addBookToCollection(books.collection1.Git);
      // Handle alert and verify alert message
      cy.verifyWindowAlertText(`Book added to your collection.`);
      // Navigate to user profile and verify that book is in collection table
      navigateTo.profile();
      cy.get('.rt-tbody').find('.rt-tr-group').first().should('contain', books.collection1.Git);
    });
  });
});

Code explanation:

Line 3-6: we are importing all page object classes we need to use here.
Line 10-15: Preconditions: We are navigating to login page and performing login. Notice how we use page objects to do that, we are not writing actions inside of test case.
Line 18-25: Cleanup: We are deleting book from user table and verifying it is deleted. afterEach or so called cleanup will be executed after each test case, but it is usually written like this - after beforeEach hook. And then, we are writing actual test cases after we defined preconditions and cleanup states.
Line 27-40: Actual test case. We are navigating to book store from profile, we are loading fixture with books, adding one book from collection, we are verifying that alert is called with proper text (utilising custom command we wrote before), we are navigating back to profile page and asserting that book is added to user table.

For this test case, we don’t need additional page objects, we have all we need in existing ones. So let’s translate this test case into automated one:

1: Create new test file called deleteBookFromProfile.cy.js and write following code inside:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Delete Book From Collection', () => {
  // Perform login
  beforeEach('Perform login', () => {
    navigateTo.login();
    cy.fixture('users').then((users) => {
      auth.login(users.user2.username, users.user2.password);
    });
  });

  // Add book to collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStoreFromProfile();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.SpeakingJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete the book from collection
  after('Delete book from profile collection', () => {
    cy.fixture('books').then((books) => {
      profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'ok');
      cy.verifyWindowAlertText(`Book deleted.`);
    });
  });

  it('Check deleting book from profile collection - confirm deletion', () => {
    cy.fixture('books').then((books) => {
      // Navigate to user profile
      navigateTo.profile();
      // Check if book is in the collection table
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.SpeakingJS);
      // Delete book from table - confirm deletion
      profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'ok');
      // Handle delete alert and verify message
      cy.verifyWindowAlertText(`Book deleted.`);
      // Verify that book is no longer in collection table and that table is empty
      cy.get('.rt-tbody').should('not.contain', books.collection1.SpeakingJS);
      cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
    });
  });

  it('Check deleting book from profile collection - decline deletion', () => {
    cy.fixture('books').then((books) => {
      // Navigate to user profile
      navigateTo.profile();
      // Check if book is in the collection table
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.SpeakingJS);
      // Cancel book deletion
      profileActions.deleteBookFromTable(books.collection1.SpeakingJS, 'cancel');
      // Verify that book is still in the table
      cy.get('.rt-tbody').should('contain', books.collection1.SpeakingJS);
    });
  });
});

Code explanation:

Lines 3-6: We are importing all page object classes we need
Lines 10-15: We are navigating to login page and performing login
Lines 18-24: We are adding book in collection (this is also precondition)
Lines 27-32: After last test we are deleting remaining book from collection
Lines 34-51: First test case, We are navigating to profile, verifying that book is in the table, we are clicking on delete icon and confirming deletion, we are checking alert and that book is no longer in the table.
Lines 53-68: Second test case, similar to first, except on line 55 we are providing ‘cancel’ argument to cancel deletion dialog and after we are verifying that book is still in the table.

1: For this test case we need to add one action in profile page object file (to click on book in user table collection and open details), so now it will look like this:

export class ProfileActions {
  deleteBookFromTable(book_name, dialog_option) {
    // Find delete button for certain book name and delete book from table
    cy.get('.rt-tbody')
      .contains('.rt-tr-group', book_name)
      .then((row) => {
        cy.wrap(row).find('#delete-record-undefined').click();
        cy.get(`#closeSmallModal-${dialog_option}`).click();
      });
  }

  checkBookData(book_name) {
    // Navigate to book info (open book from table)
    cy.get('.rt-tbody').find('.rt-tr-group').first().contains(book_name).click();
  }
}

export const profileActions = new ProfileActions();

Code explanation:

As you can see on line 12 , we added new function checkBookData that will take book name as parameter and it will perform the action of finding the book by name in user table and clicking on it, in order to open book details.

2: With all this, we can translate our test case into automated one. Create a new test file and call it checkBookInfo.cy.js.Write the following code inside:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { profileActions } from '../../support/bookstore_page_objects/profile';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Collections: Check Book Info', () => {
  // Perform login
  beforeEach('Perform login', () => {
    navigateTo.login();
    cy.fixture('users').then((users) => {
      auth.login(users.user2.username, users.user2.password);
    });
  });

  // Add book to book collection
  beforeEach('Add book to profile collection', () => {
    navigateTo.bookStoreFromProfile();
    cy.fixture('books').then((books) => {
      bookActions.addBookToCollection(books.collection1.DesignPatternsJS);
      cy.verifyWindowAlertText(`Book added to your collection.`);
    });
  });

  // Delete book from collection
  afterEach('Delete book from profile collection', () => {
    navigateTo.profile();
    cy.fixture('books').then((books) => {
      profileActions.deleteBookFromTable(books.collection1.DesignPatternsJS, 'ok');
      cy.verifyWindowAlertText(`Book deleted.`);
    });
  });

  it('Check book info from profile table', () => {
    // Navigate to user profile
    navigateTo.profile();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Click on book in collection to open book info
      profileActions.checkBookData(books.collection1.DesignPatternsJS);
    });
    // Define book info elements
    const bookDataElements = [
      '#ISBN-label',
      '#title-label',
      '#subtitle-label',
      '#author-label',
      '#publisher-label',
      '#pages-label',
      '#description-label',
      '#website-label',
    ];
    // Check book info elements
    cy.elementVisible(bookDataElements);
    // Define data about the book
    const bookData = [
      '9781449331818',
      'Learning JavaScript Design Patterns',
      `A JavaScript and jQuery Developer's Guide`,
      'Addy Osmani',
      `O'Reilly Media`,
      '254',
    ];
    // Check data about the book
    cy.textExists(bookData);
  });
});

Code explanation:

Lines 3-6: we are importing all page object classes we need for this test
Lines 10-15: Precondition - login
Lines 18-24: Precondition - adding book to user collection
Lines 27-33: Cleanup/Postcondition - deleting book from user table
Lines 35-67: Our test case - we are navigating to user profile and using previously created method to open book we are clicking on the book in table to open details. We are then storing all elements from book details and all text from book details that interest us into two arrays, and we are calling custom commands we created earlier to verify if all elements and texts is present on the page.

1: For this test case we need to add one function for searching book, inside book_store.js page object. Write additional function so that now you have this inside:

export class BookActions {
  addBookToCollection(book_name) {
    cy.contains(book_name).click();
    cy.get('.text-right > #addNewRecordButton').click();
  }

  searchCollection(book_name) {
    cy.get('#searchBox').type(book_name);
  }
}

export const bookActions = new BookActions();

Code explanation:

On line 7 we added new function searchCollection that will type book name we provide in test, in search box of the book store.

2: With this, we can create our test case searchBookstore.cy.js and write this code in it:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { bookActions } from '../../support/bookstore_page_objects/book_store';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Bookstore: Search For Book', () => {
  // Perform login
  beforeEach('Perform login', () => {
    navigateTo.login();
    cy.fixture('users').then((users) => {
      auth.login(users.user2.username, users.user2.password);
    });
  });

  it('Check searching for existing book in book store', () => {
    // Navigate to bookstore
    navigateTo.bookStoreFromProfile();
    // Load books fixture
    cy.fixture('books').then((books) => {
      // Perform book search
      bookActions.searchCollection(books.collection1.DesignPatternsJS);
      // Verify that there is a book in filtered table (in search result)
      cy.get('.rt-tbody')
        .find('.rt-tr-group')
        .first()
        .should('contain', books.collection1.DesignPatternsJS);
    });
  });

  it('Check searching for non-existing book in book store', () => {
    // Define invalid book name
    const invalid_book_name = 'Game of Thrones';
    // Navigate to bookstore
    navigateTo.bookStoreFromProfile();
    // Perform book search
    bookActions.searchCollection(invalid_book_name);
    // Assert that there are no search results (no book in the table and table is empty)
    cy.get('.rt-tbody').should('not.contain', invalid_book_name);
    cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
  });
});

Code explanation:

Lines 3-5: we are importing page objects
Lines 9-14: we are doing precondition to login
Lines 16-29: First test case, using page objects we are typing in search box of bookstore, searching for book and asserting that we found it
Lines 31-41: Second test case, same as above but in this case we defined non-existing title and we are checking that table doesn’t contain it.

1: For this test case we will add new action in auth page object that will allow us to log out. Now auth.js page object file should look like this:

export class Auth {
  login(user_name, password) {
    cy.get('#userName').type(user_name);
    cy.get('#password').type(password);
    cy.get('#login').click();
  }

  logout() {
    cy.get('#submit').should('contain', 'Log out').click();
  }
}

export const auth = new Auth();

Code explanation:

On the line 7 we added logout function that will click on log out button on user profile and preform log out.

2: And now we can write out test case logout.cy.js:

/// <reference types="Cypress" />

import { auth } from '../../support/bookstore_page_objects/auth';
import { navigateTo } from '../../support/bookstore_page_objects/navigation';

describe('Auth: Log out user', () => {
  // Perform login
  beforeEach('Perform login', () => {
    navigateTo.login();
    cy.fixture('users').then((users) => {
      auth.login(users.user2.username, users.user2.password);
    });
  });

  it('Check logging out user', () => {
    // Assert that user is on profile page
    cy.url().should('contain', '/profile');
    // Perform log out
    auth.logout();
    // Assert that user is on login page
    cy.url().should('contain', '/login');
  });
});

Code explanation:

Same as previous test cases we are importing page objects, writing preconditions, and then writing core of our test - in this case we are using logout action from auth page objects to perform log out. Of course, we are adding assertion to verify if user is actually logged out.

HOMEWORK:

For homework, you can add more scenarios for bookstore, following the above structure. Also read more about page objects from Internet sources, there are plenty 😄

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: reusability, book store tests"

git push

SEE YOU IN LESSON 10!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 8: Elements manipulation - Tooltips, Alerts, Frames

Viktorija Filipov — Sun, 11 Jun 2023 13:42:29 +0000

Tooltips

Tooltips are web elements that are usually used to provide additional explanations to the user, usually when the user hovers over another element. They look something like this: the user hovered over a button and a tooltip appeared.

So, let’s create some tooltip tests:

1: Create a new test file under e2e/elements_manipulation and call it, for example, tooltips.cy.js.

2: Write the following tests inside:



/// <reference types="Cypress" />

describe('Tooltips: Tooltips actions', () => {
    beforeEach('Navigate to Tooltips page', () => {
        cy.visit('/tool-tips');
    });

    it('Check button tooltip hover', () => {
        //Perform hover over button element
        cy.get('#toolTipButton').trigger('mouseover');
        //Assert that tooltip is visible and contains expected text
        cy.get('.tooltip-inner').should('be.visible').and('contain', 'You hovered over the Button');
    });

    it('Check input tooltip hover', () => {
        //Perform hover over input element
        cy.get('#toolTipTextField').trigger('mouseover');
        //Assert that tooltip is visible and contains expected text
        cy.get('.tooltip-inner').should('be.visible').and('contain', 'You hovered over the text field');
    });

    it('Check text tooltip hover', () => {
        //Perform hover over text element
        cy.contains('Contrary').trigger('mouseover');
        //Assert that tooltip is visible and contains expected text
        cy.get('.tooltip-inner').should('be.visible').and('contain', 'You hovered over the Contrary');
    });
});

Code explanation:

Before each test, we will first navigate to our desired test page with tooltips: page

Test 1 (Tooltip over button):

Line 10: We will get ID of our button, and we will use Cypress trigger event to simulate mouseover action (hover action)

Upon previous step, a tooltip should appear.

Line 12: We are getting a tooltip locator, and we are asserting that it is visible and contains correct text.

Test 2 (Tooltip over input):

Line 16: We will get ID of our input field, and we will use Cypress trigger event to simulate mouseover action (hover action)

Upon previous step, a tooltip should appear.

Line 19: We are getting a tooltip locator, and we are asserting that it is visible and contains correct text.

Test 3 (Tooltip over text):

Line 24: We will get text elements by cypress “contains” method of getting element, and we will use Cypress trigger event to simulate mouseover action (hover action).

Upon previous step, a tooltip should appear.

Line 26: We are getting a tooltip locator, and we are asserting that it is visible and contains correct text.

ℹ️ Learn more about trigger event: trigger

ℹ️ Learn more about tooltips: tooltips

ℹ️ Tip: When trying to get the element of a tooltip (inspect tooltip element via developer tools in Chrome or other browser), tooltip will disappear, and you wouldn’t be able to see tooltip in the DOM. My advice on how to find a tooltip element selector is to write a test that will do a hover action and display the tooltip, and then inside Cypress CLI desktop app, in the debugger, try to inspect the tooltip element. Cypress CLI freezes the state of the browser, so the tooltip will stay in its place, and you will be able to get tooltip selector/locator.

Alerts

Alerts are elements that display a box in a browser window and usually contains some option in it. They look something like this:

So, let’s write some tests for alerts to see them in action.

1: Create a new test file under e2e/elements_manipulation and call it, for example, alerts.cy.js.

2: Write the following tests inside:



/// <reference types="Cypress" />

describe('Alerts: Alerts actions', () => {
    beforeEach('Navigate to Alerts page', () => {
        cy.visit('/alerts');
    });

    it('Check alert confirmation', () => {
        //Create a stub method on window confirm alert
        const stub = cy.stub();
        cy.on('window:confirm', stub);
        //Click on alert confirm button and assert that alert is called with correct text
        cy.get('#confirmButton').click().then(() => {
            expect(stub.getCall(0)).to.be.calledWith('Do you confirm action?');
        });
        //Select ok in alert
        cy.on('window:confirm', () => true);
        //Assert that confirmation text is visible
        cy.contains('You selected Ok').should('be.visible');
    });

    it('Check alert cancellation', () => {
        //Create a stub method on window confirm alert
        const stub = cy.stub();
        cy.on('window:confirm', stub);
        //Click on alert confirm button and assert that alert is called with correct text
        cy.get('#confirmButton').click().then(() => {
            expect(stub.getCall(0)).to.be.calledWith('Do you confirm action?');
        });
        //Select cancel in alert
        cy.on('window:confirm', () => false);
        //Assert that confirmation text is visible
        cy.contains('You selected Cancel').should('be.visible');
    });
});

Code explanation:

Before each test, we will first navigate to our desired test page with alerts: page. We will automate an alert that has two options, to confirm or cancel.

Test 1 (Check if user can do confirm action on alert event):

Line 10: We will first create a stub. A stub is a way to modify a function and delegate control over its behaviour to you (the programmer). You generally stub a function when it has side effects you are trying to control. In this case of alert’s, we can’t just take the element of ok/cancel button and click on it because Cypress is unable to interact with them as normal web elements.*

Line 11: We are observing browser event window:confirm (alert box) and applying stub because we want to interact with it when it happens.

Line 13: We are clicking on the third button “Click me” in our app and upon that click ->

Line 14: we are expecting that our stub function was called with correct alert text

Line 17: we are performing an action on window:confirm and providing value “true”, which is equal to the action of clicking on “Ok” button

Line 19: We are asserting that correct confirmation text is displayed on our page after alert selection

Test 2 (Check if user can do cancel action on alert event):

Line 24: We will first create a stub.

Line 25: We are observing browser event window:confirm (alert box) and applying stub because we want to interact with it when it happens.

Line 27: We are clicking on the third button “Click me” in our app and upon that click ->

Line 28: we are expecting that our stub function was called with correct alert text

Line 31: we are performing an action on window:confirm and providing value “false”, which is equal to the action of clicking on “Cancel” button

Line 33: We are asserting that correct cancellation text is displayed on our page after alert selection

ℹ️ *Cypress handles alerts in its own way. It performs auto accept of the alert message without asking user to accept explicit. There is no way to read ALERT message in inbuilt cypress. But there is a way hitting browser command “window:alert or window:confirm” you can read the text present in alert window.

ℹ️ Learn more about alerts: alerts

Frames

A frame, or iFrame, is an HTML element that loads another HTML page within the document. It essentially puts another webpage within the parent page. They are commonly used for inserting payment method forms from third parties, advertisements, embedded videos, web analytics and interactive content.

You can’t really see that element is an iframe until you open developer tools and check DOM. In case of iframes, DOM usually displays it like this:

So, let’s write some tests for iframes to see them in action.

1: Create a new test file under e2e/elements_manipulation and call it, for example, iframe.cy.js.

2: Write the following tests inside:



/// <reference types="Cypress" />

describe('iFrames: iFrames actions', () => {
    before('Navigate to iFrame page', () => {
        cy.visit('/frames');
    });

    it('Check iFrame content', () => {
        //Create function to return the iframe and assert that it is not empty
        const getIframeBody = () => {
            return cy
                .get('#frame1')
                .its('0.contentDocument.body')
                .should('not.be.empty')
                .then(cy.wrap);
        };
        //Assert that iframe is visible
        getIframeBody().should('be.visible');
        //Assert that iframe contains heading with correct text
        getIframeBody().find('#sampleHeading').should('contain', 'This is a sample page');
    });
});

Code explanation:

Before our test, we will visit our test page with iframes: page

In this test we will get the first iframe and assert that it is visible and contains correct text.

Line 10 to line 16: we are creating a new function that will return our iframe with all its content. We are getting the ID of an iframe, it’s body, we are asserting that is not empty and we are wrapping all that in our function called for example getIframeBody.

Now that we have a function that returns our iframe, we can call it and find elements that are inside of the iframe. In our case, we only have text inside.

Line 18: We are asserting that our iframe is visible

Line 20: Since we only have some text in it, we are getting ID of our text and asserting that it contains correct text. *

ℹ️ *In real life, iframes are usually more complex, for example it can be a credit card payment form where you need to fill in credit card details in order to pay for something. So if you want to automate that kind of scenario, you would again create exactly the same function as we did here and call it to find all input elements, buttons etc inside the iframe and interact with it.

ℹ️ Learn more about iframes: iframes

HOMEWORK

1: Write more scenarios for above elements if you can think of some (we didn’t cover all alert cases, so you can try to write more of them)

2: Visit links provided in the lesson, learn and understand what are tooltips, iframes, alerts. Practice how to find tooltip selector, how to get iframe and interact with it, how to manipulate alerts.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: tooltip, alert, iframe tests"

git push

SEE YOU IN LESSON 9!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 7: Elements manipulation - Table And Upload

Viktorija Filipov — Sun, 28 May 2023 21:12:46 +0000

Tables

Tables are collections of different web elements, usually consisting of multiple editable/non-editable fields in a form of inputs, text areas, buttons, dropdowns and similar.

So, let’s use our knowledge from previous lessons to write some new test cases related to tables:

1: Create a new test file under e2e/elements_manipulation and call it for example tables.cy.js.

2: Write the following tests inside:



/// <reference types="Cypress" />

describe('Tables: Tables actions', () => {
  beforeEach('Navigate to tables page', () => {
    // Visit tables page
    // Table records return to default after page refresh
    cy.visit('/webtables');
  });

  it('Check finding and editing a record', () => {
    // Get the table, find the row with record Alden
    cy.get('.rt-tbody')
      .contains('.rt-tr-group', 'Alden')
      .then((row) => {
        // Click on edit button for Alden record
        cy.wrap(row).find('[title="Edit"]').click();
        // Edit first and last name
        cy.get('#firstName').clear().type('Harvey');
        cy.get('#lastName').clear().type('Specter');
        // Submit edit form
        cy.get('#submit').click();
        // Assert that first and last name are changed
        cy.wrap(row).find('.rt-td').eq(0).should('contain', 'Harvey');
        cy.wrap(row).find('.rt-td').eq(1).should('contain', 'Specter');
      });
  });

  it('Check finding and deleting a record', () => {
    // Get the table, find the row with record Alden
    cy.get('.rt-tbody')
      .contains('.rt-tr-group', 'Alden')
      .then((row) => {
        // Click on delete button for Alden record
        cy.wrap(row).find('[title="Delete"]').click();
      });
    // Assert that table does not contain Alden record
    cy.get('.rt-tbody').should('not.contain', 'Alden');
    // Perform search for Alden record
    cy.get('#searchBox').type('Alden');
    // Assert that Alden record does not exist and "No rows found" message is displayed
    cy.get('.rt-tbody').should('not.contain', 'Alden');
    cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
  });

  it('Check search for different age records', () => {
    // Define age group
    const ageGroup = [29, 39, 45, 77];
    // For each age group perform following
    cy.wrap(ageGroup).each((age) => {
      // Type age into search input field
      cy.get('#searchBox').clear().type(age);
      // If age is 77 assert that record doesn't exist in the table, otherwise assert that record is present
      if (age === 77) {
        cy.get('.rt-tbody').find('.rt-tr-group').first().should('not.contain', age);
        cy.get('.rt-noData').should('contain', 'No rows found').should('be.visible');
      } else {
        cy.get('.rt-tbody').find('.rt-tr-group').first().should('contain', age);
        cy.get('.rt-tbody').contains('.rt-tr-group', age).should('have.length', 1);
      }
    });
  });

  xit('Check adding a new record - Bad code practice', () => {
    // Click on Add button
    cy.get('#addNewRecordButton').click();
    // Fill new record form
    cy.get('#firstName').type('Harvey');
    cy.get('#lastName').type('Specter');
    cy.get('#userEmail').type('specter@example.com');
    cy.get('#age').type('40');
    cy.get('#salary').type('700000');
    cy.get('#department').type('legal');
    cy.get('#submit').click();
    // Assert that new record is present in the table with correct values
    cy.get('.rt-tbody')
      .contains('.rt-tr-group', 'Harvey')
      .then((row) => {
        cy.wrap(row).find('.rt-td').eq(0).should('contain', 'Harvey');
        cy.wrap(row).find('.rt-td').eq(1).should('contain', 'Specter');
        cy.wrap(row).find('.rt-td').eq(2).should('contain', '40');
        cy.wrap(row).find('.rt-td').eq(3).should('contain', 'specter@example.com');
        cy.wrap(row).find('.rt-td').eq(4).should('contain', '700000');
        cy.wrap(row).find('.rt-td').eq(5).should('contain', 'legal');
      });
  });

  it('Check adding a new record', () => {
    // Click on Add button
    cy.get('#addNewRecordButton').click();
    cy.fixture('users').then((user) => {
      // Fill new record form
      const columnIDs = Object.keys(user.user1);
      const userData = Object.values(user.user1);

      cy.wrap(columnIDs).each((id, value) => {
        cy.get(`#${id}`).type(userData[value]);
      });
      cy.get('#submit').click();
      // Assert that new record is present in the table with correct values
      cy.get('.rt-tbody')
        .contains('.rt-tr-group', user.user1.firstName)
        .then((row) => {
          cy.wrap(userData).each((value, index) => {
            cy.wrap(row).find('.rt-td').eq(index).should('contain', value);
          });
        });
    });
  });
});

As you can see, we have multiple tests inside this test file. Before each test (line: 7) we will first visit our test page with a table page. One thing to note: This page is written in a way that if you modify the records in the table, after each page request we will get the default state of this table, meaning for each test we will have the same state of the table regardless if we modified it with teat automation or manually.

Let’s break this test file into multiple explanations for each test:

Test 1: Check finding and editing a record

For this test case, we want to edit the row with record under name “Alden”. We want to edit his first and last name to be “Harvey Specter” and check if the name is actually changed in the table.

Code explanation:

On the line: 12 we are getting the entire table body

Line: 13 After we got the entire body, we are searching for the row that contains text ‘Alden’

Then line: 14, we are creating a function that will return every data in that row

Line: 16 we are wrapping the row data, and we are finding ‘Edit’ button element, and we are clicking on it

After the edit modal is opened, on the lines 18 and 19 we are editing first and last name and typing new values

On the line: 21, we are submitting the form and modal is closing

Line 23: from the wrapped row data, we are finding first column and asserting that it contains updated first name

Line 24: from the wrapped row data, we are finding the second column and asserting that it contains updated last name

Why are we not using IDs for “Edit” button, and why are we wrapping specific row data to get selectors? Because they have indexes, and they are not unique in this case, and we want to make sure we changed only the ‘Alden’ record, in case the records in the table change the order in the future (developer changed the order etc).

Test 2: Check finding and deleting a record

For this test case, we want to delete a record from the table, in this case - record with first name ‘Alden’. We also want to check if a record is deleted by asserting that the table does not contain that record upon deletion, and we are checking that if we search the table record does not appear, but we have a text ‘No rows found’.

Code explanation:

On the line: 30, we are getting the entire table body

Line 31: We are After we got the entire body, we are searching for the row that contains text ‘Alden’

Line 32: we are creating a function that will return every data in that row

Line 34: we are wrapping the row data, and we are finding ‘Delete’ button element, and we are clicking on it

Line 37: We are asserting that table body does not contain record ‘Alden’ any more (row is deleted)

Line 39: We are typing in the search box text ‘Alden’ to search the entire table for that record

Line 41: We are asserting that table body does not contain record ‘Alden’

Line 42: We are asserting that ‘No rows found’ text is visible

Test 3: Check search for different age records

For this test case, we want to search the table by age number. Let’s say we want to search three existing age records and one non-existing. We will search each age group and for each one of them we will assert that they either exist in the table or not.

Code explanation:

On the line: 47 we are storing age records as an array in a variable. As a general rule, always declare a variable with const unless you know that the value will change.

Line 49: We are wrapping all of our values from the array and for each one of them we are running a loop function explained below each

Line 51: We will first clear our search box (because after first search, age text stays in input field), and we will then type age with value from the array

Since we have age values that exist and don’t exist, we need to split assertions in two conditionals.

Line: 53: If age is equal to 77 (age that should not exist in the table)

Line 54: we will assert that first row doesn’t contain this age (for this test, we only have one or no records in the table, so it is enough to check only first row as search result)

Line 55: We will also check that ‘No rows found’ message is displayed.

Line 56: Another condition (else) - for age values that do exist, we will run other assertions as below

Line 57: We will assert that first row contain the searched age

Line 58: We will assert that there is only one row with that age in the table

Test 4: Check adding a new record - Bad code practice

For this test case, we want to submit a new record in the table by clicking on Add option and submitting a new record modal. We also want to check that the record is properly added in the table and contains all values we provided. The reason why we have a note that this is a bad code practice and why the test is skipped (xit) is because there is a better way to write this piece of code to be more reusable using basic JS concepts (we will see this in the Test 5 that is identical in functionality as this one, just written with better code style).

Code explanation:

Line 65: We will click on ‘Add’ button

When modal opens from line 67 to line 72 we will fill all the info that is needed

Line 73: We will submit a modal with new record info

Line 75: We will get entire table body

Line 76: We will find a row that contains our record’s first name

Line 77: we will get data from that row

Line 78-83: We will wrap row data find each of the columns by index and assert that correct value that we provided before is written in the appropriate column. As you can see there is a lot of code duplication here, and in step 2 so in the next test we will write it in a shorter and better way.

Test 5: Check adding a new record

This test will do the exact same things as previous one, but we will organise it to have less repetitive and more easily maintained code.

For the purpose of this test, we will store new user data in a form of fixture, so that if it is needed we can easily find and edit this data. Let’s create a new users.json file under fixtures folder and insert following data inside:



{
  "user1": {
    "firstName": "Harvey",
    "lastName": "Specter",
    "age": "40",
    "userEmail": "specter@example.com",
    "salary": "700000",
    "department": "legal"
  }
}

Code explanation:

Same as previously, on the line: 89 we are clicking on ‘Add’ button to open the modal to add new record

On the line: 90, we are calling our ‘users’ fixture to load, then we are creating a function for the test where we will use this data

Line 92: we are creating a new variable columnIDs and for this variable we will read object keys from our fixture file for user1 data (object keys in this case are actually names of selector IDs)

Line 93: we are creating a new variable userData and for this variable we will read object values from our fixture file for user1 data (object values in this case are actual user data we are inserting in a modal for adding new user)

Line 95: We will warp all our selectors for column IDs (our object keys) and for each one of them → next step

Line 96: we will use object keys as selectors, get them, and type user data values from it’s pair - user object values (this is actually a short way of writing what we had in previous test from line 67 to 72). See how we reduced the code here and made it more maintainable for the future?

Line 98: We will click on submit button in the modal

Line 100: We want to asset that each column for our record contains value that we inserted for the user. So, We are getting entire table here

Line 101: We are finding a row that contains our user’s first name

Line 102: with the data from our specific row we are creating a function to make assertions

Line 103: We are wrapping our user data (object values from fixture file), and for each one of them we are retrieving it’s value (actual value from fixtures file) and index (0,1,2..) that will serve as index for table column in next step

Line 104: we are wrapping entire data from the row, we are finding index of each column, and we are asserting that it has correct value defined in the fixtures file. This is basically the same thing we did in previous test from the line 78 to 83. Again, see how we made it better here using different code style?

ℹ️ Learn more about JS objects:

Keys Values Entries
JS Objects

Upload

Upload functionality allows us to submit a file to our web app. There is a simple way of how to handle that in Cypress.

Let’s create our upload test and explain it.

1: Install a library for uploading files, run in VS terminal following command:

npm install cypress-file-upload

2: Add this line to support/commands.js file:

import 'cypress-file-upload';

3: First create a new test file called upload.cy.js under e2e/elements_manipulation folder.

4: Write following code inside:



/// <reference types="Cypress" />

describe('Upload: Upload actions', () => {
  before('Navigate to upload page', () => {
    cy.visit('/upload-download');
  });

  it('Check upload action', () => {
    // Upload file
    cy.get('#uploadFile').attachFile('pic.png');
    // Assert that path message is displayed
    cy.get('#uploadedFilePath').should('have.text', `C:\\fakepath\\pic.png`);
  });
});

5: Take this picture (download it, right click, save image as..) and move it to fixtures folder. Rename it to be for example: pic.png

Code explanation:

On the line: 5 we are visiting our app, and page containing upload functionality

You will see a “Choose file” input element, so what we want to do is to upload our picture to that element. To do that we will use attachFile() method from our library. You can see on line: 10 we are getting our input ID selector and performing upload over it. We also need to provide exact name and extension of our file, in this case pic.png. Cypress will automatically look for it in fixtures folder.

After doing that, our app will give us a text of a picture file location on the server, so for us in this case - that is a confirmation that image has been uploaded. We want to assert that text is present, so on line: 12 we are writing assertion to confirm that our text element contains text with correct path.

HOMEWORK:

Write more scenarios for tables (searching, sorting, adding/removing records, etc). Visit links provided in the lesson, learn and understand Objects and Objects methods in JS.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: table, upload tests"

git push

SEE YOU IN LESSON 8!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 6: Elements manipulation - Lists, Date picker

Viktorija Filipov — Sat, 20 May 2023 16:44:21 +0000

Lists

As you have already seen in almost every application you used, developed, tested, lists are very common web elements. Menus, Dropdowns and similar selections are a common component for web applications.

ℹ️ Learn more about lists actions:
select
testing lists
each

So, let’s write some tests for lists:

1: Create a new test file under e2e/elements_manipulation and call it, for example, lists.cy.js.

2: Write the following tests inside:



/// <reference types="Cypress" />

describe('Lists: Lists actions', () => {
  beforeEach('Navigate to lists page', () => {
    cy.visit('/select-menu');
  });

  it('Check selection of all list options - select method - colors menu', () => {
    // Load colors fixure json file to assert if all colors are present
    cy.fixture('colors').then((colors) => {
      // Get all options in the menu, get each option and indexes
      cy.get('#oldSelectMenu option').each((option, index) => {
        // Get option text
        const optionText = option.text();
        // Select each option and assert that it has correct option value and text
        cy.get('#oldSelectMenu')
          .select(optionText)
          .should('have.value', option.val())
          .contains(colors[index]);
      });
    });
  });

  it('Check selection of single list option - click method - title menu', () => {
    // Click on dropdown
    cy.get('#selectOne').click();
    // Select one option
    cy.get('#react-select-3-option-0-4').click();
    // Assert that dropdown has correct text after selection
    cy.get('#selectOne').contains('Prof.');
  });
});

3: Delete example.json file in cypress/fixtures folder, and create new one called colors.json. Write following data in it.



{
  "0": "Red",
  "1": "Blue",
  "2": "Green",
  "3": "Yellow",
  "4": "Purple",
  "5": "Black",
  "6": "White",
  "7": "Voilet",
  "8": "Indigo",
  "9": "Magenta",
  "10": "Aqua"
}

Code explanation:

In our test file, we are first visiting our app’s page dedicated for testing lists-menus before each test starts page.

In the first test case, the test subject is the menu with colours (Old Style Select Menu). We want to test values and text of each option in the menu.

Line 10: We are wrapping the entire action/assertion with a fixture, because we want to load and use its content (from colors.json file) for colour results assertions. (Loading once instead of each time assertion is called, that is why we call it outside the selection loop.)

Line 12: We are getting dropdown options and for each option we are getting its value and index.

Line 14: For each option we are getting the text (Red, Blue, etc.)

Line 16-17: We are using Cypress option select() instead of click() to select each value, and we are able to use this because this element has select tag in DOM. Because we are inside the loop, this will not select all options at once, but one after another.

Line 18-19: For each option selection, we are asserting that it contains the proper value and that colours by indexes match with our fixture file content (colour names) in that particular order.

In the second test case, we just want to select one option in the menu of titles. For this particular example, we can’t use select() function because this app does not provide select tag for this menu. There is no need for looping here, since we want to check only one option.

Line 26: We are clicking on the menu to open it.

Line 28: We are clicking on one option in the menu.

Line 30: We are asserting that menu element has a selection that we chose.

ℹ️ Learn more about fixtures: fixtures

ℹ️ Learn more about different types of JS loops you can also use in the tests: loops

👉 It is very important to understand loop logic. As someone who writes test automation, you will often have situations where you will have to tests different options in lists, tables etc, so loops are an excellent method to avoid code repetition and make test execution faster.

Date picker

Date picker elements let users select a date or range of dates. They are usually tied to the input field. Now that we know how to perform actions over buttons, input fields and lists, let’s write a few date picker tests that are a combination of what we learned before.

1: Create a new test file under e2e/elements_manipulation and call it, for example, datepicker.cy.js. Write the following test inside.



/// <reference types="Cypress" />

describe('Date picker: Date picker actions', () => {
  beforeEach('Navigate to date picker page', () => {
    cy.visit('/date-picker');
  });

  it('Check fixed date selection', () => {
    // Open date picker
    cy.get('#datePickerMonthYearInput').click();
    // Select year
    cy.get('.react-datepicker__year-select').select('2030');
    // Select month
    cy.get('.react-datepicker__month-select').select('June');
    // Select day
    cy.get(`.react-datepicker__day--0${23}`).first().click();
    // Assert input date value
    cy.get('#datePickerMonthYearInput').should('have.value', '06/23/2030');
  });

  it('Check dynamic date selection', () => {
    // Increment Date by 1 month
    const date = new Date();
    date.setMonth(date.getMonth() + 1);
    // Set date to 23rd day of next month
    const year = date.getFullYear();
    const month = date.getMonth();
    const day = 23;
    // Open date picker
    cy.get('#datePickerMonthYearInput').click();
    // Select year
    cy.get('.react-datepicker__year-select').select(`${year}`);
    // Select month
    cy.get('.react-datepicker__month-select').select(`${month}`);
    // Select day
    cy.get(`.react-datepicker__day--0${day}`).first().click();
    // Assert input date value
    cy.get('#datePickerMonthYearInput').should(
      'have.value',
      `${`${month + 1}`.padStart(2, '0')}/${day}/${year}`
    );
  });

  it('Check applying date value directly in the input field', () => {
    // Clear date input and type new date
    cy.get('#datePickerMonthYearInput').clear().type('06/23/2030');
    // Assert input date value
    cy.get('#datePickerMonthYearInput').should('have.value', '06/23/2030');
  });
});

Code explanation:

In our test file, we are first visiting our app’s page dedicated for testing date pickers before each test starts page.

Test 1 (we are selecting fixed date value):

Line 10: First, we are clicking on date picker input to open it.

Line 12: We are selecting fixed value for the year.

Line 14: We are selecting fixed value for the month.

Line 16: We are selecting fixed value for date, and taking first one, in case that date picker shows duplicate value for next/previous month.

Line 18: We are asserting that date input has a new value - our selected value.

Test 2 (we are selecting date dynamically):

Line 23: We are initiating Date object.

Line 24: We are setting month in Date object to always be increased by 1 month from current month.

Line 26: We are getting year from Date object

Line 27: We are getting month from Date object

Line 28: We are creating constant to be used as value of the day

Line 30: We are opening date picker

Lines 32 - 36: We are selecting year, month, day in date picker

Lines 38 - 41: We are asserting that date input has the correct value that we have set for the date. Because of different indexing of month from Date object and dropdown value, we are adding 1 to the month and if value is less than 10, we are adding 0 in order to respect formatting of date input field.

Test 3 (we are inserting fixed date value directly in the input field without selection):

Line 46: We are clearing the default value from the input field, and we are typing a new fixed value.

Line 48: We are asserting that date input has a new value - our selected value.

👉 It is always advisable NOT to use fixed values for dates because tests will fail once that date is passed etc. depending on use case on the project. Whenever possible use calculations, dynamic values and native JS Date object, or other library such as moment.js. We have fixed examples here just for learning purposes, to be familiar with multiple ways of how you can interact with date pickers.

ℹ️ Learn more about JS Date Objects: date objects

HOMEWORK:

Add more scenarios that will check other lists on our lists page, or other dropdowns in our Demo app. Play with selections and assertions. Try to automate multi-select list.
Add more scenarios for date picker. Try to navigate through different months using left/right arrow navigation. Try to automate second date picker that contains time as well. Play with time calculations.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: lists, date pickers tests"

git push

SEE YOU IN LESSON 7!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 5: Elements manipulation - Button, Input, Radio Button, Checkbox

Viktorija Filipov — Sat, 20 May 2023 15:16:55 +0000

Button Actions

Button actions - clicks, are one of the most used in UI web automation. In order to write tests, you will have to learn how to click on different types of buttons, so let’s cover the most popular ones.

Learn more about button actions:
ℹ️ click
ℹ️ interacting with elements

1: Create new folder under e2e and call it for example elements_manipulation. Under that folder, create new test file and call it for example button.cy.js.

2: Write the following test inside:

/// <reference types="Cypress" />

describe('Buttons: Button actions', () => {
  before('Navigate to buttons page', () => {
    cy.visit('/buttons');
  });

  it('Check different button actions', () => {
    // Double click on button
    cy.get('#doubleClickBtn').dblclick();
    cy.contains('You have done a double click').should('be.visible');

    // Right-click on button
    cy.get('#rightClickBtn').rightclick();
    cy.contains('You have done a right click').should('be.visible');

    // Click on button
    cy.get('[class="btn btn-primary"]').then((buttons) => {
      cy.wrap(buttons).eq(2).click();
      cy.contains('You have done a dynamic click').should('be.visible');
    });
  });
});

Code explanation:

We are visiting our app’s page dedicated for testing buttons (page). We are using before hook for that, since we only have 1 test.

Inside the test body, we can see 3 examples: how to perform double click on the button, how to perform right click and a single dynamic click.

Double click: we are locating our button and performing double click action dblclick() and after that we are performing assertion to confirm that proper text is visible after we double-clicked on the button.
Right-click: we are locating our button and performing right click action rightclick() and after that we are performing assertion to confirm that proper text is visible after we right-clicked on the button.
Single click: we are locating our button and performing single click action click() and after that we are performing assertion to confirm that proper text is visible after we clicked on the button. You will notice that for this button we didn’t have a unique id, compared to others, so we wrapped the class it belongs to into a JQuery object, and we selected the third element in that class (our subject button).

3: Execute the test: Open cypress CLI and run this test. Have a look at the logs.

Input Actions

Inputs are also very common web elements you will have to interact with, so let’s write one test to see how we can do it.

Learn more about input actions:
ℹ️ type
ℹ️ clear

1: Create new test file under e2e/elements_manipulation and call it for example input.cy.js. Write the following test inside.

/// <reference types="Cypress" />

describe('Inputs: Input actions', () => {
  before('Navigate to input page', () => {
    cy.visit('/text-box');
  });

  it('Check different input actions', () => {
    // Fill the form details
    cy.get('#userName').type('Arya Stark');
    cy.get('#userEmail').type('noone@example.com');
    cy.get('#currentAddress').type('Braavos, East of Westeros');
    cy.get('#permanentAddress').type('Winterfell,{enter}Kingdom of the North,{enter}Westeros');

    // Submit form and check if expected text is dispalyed
    cy.get('#submit').click();

    // Example assertions - Verify that we got correct output for name and email
    cy.get('#name').contains('Arya Stark');
    cy.get('#email').contains('noone@example.com');

    // Edit username input field, submit form and assert that username is changed
    cy.get('#userName').clear().type('Jon Snow');
    cy.get('#submit').click();
    cy.get('#name').contains('Jon Snow');
  });
});

Code explanation:

We are visiting our app’s page dedicated for testing inputs (text-box). We are using before hook for that, since we only have 1 test.

As you can see, on that page, we have several input fields and one submit button.

First, we should fill this form. We are entering: username, email, current address and permanent address. We are using type() cypress function to write the text. In the permanent address, you will notice that we are also simulating that the user pressed ENTER key with {enter} option, in order to write their address in multiple lines.

Then, we are clicking on submit button to submit form. Due to limitation of this app (button is of type="button" and not "submit" , we can't use native cypress option that is recommended for submitting forms (read more here )

After we submitted the form, we are doing assertions to check if we got our expected output, for example in this case let’s say we are interested to check if we got text output of name and email correctly.

Next, let’s say we want to re-submit the form with some different values of username. So, we are using cypress function clear() to delete previously added value of username, and we are typing new one.

Lastly, we are re-submitting the form, and we are checking if the name is updated to the new one.

2: Execute the test: Open Cypress CLI and run this test. Have a look at the logs.

Radio Button Actions

Radio buttons are another popular element in modern web application. Let’s see how we can test them.

ℹ️ Learn more about radio button actions:
check

1: Create a new test file under e2e/elements_manipulation and call it, for example, radioButton.cy.js. Write the following test inside.

/// <reference types="Cypress" />

describe('Radio Buttons: Radio Button actions', () => {
  before('Navigate to radio buttons page', () => {
    cy.visit('/radio-button');
  });

  it('Check different radio button actions', () => {
    cy.get('.custom-radio')
      .find('[type="radio"]')
      .then((radio) => {
        /* Get all radio buttons, select first one and verify that it is 
         checked and that we got confirmation text */
        cy.wrap(radio).first().check({ force: true }).should('be.checked');
        cy.contains('.text-success', 'Yes');

        /* Get all radio buttons, select second one and verify that it is 
         checked and that we got confirmation text */
        cy.wrap(radio).eq(1).check({ force: true }).should('be.checked');
        cy.contains('.text-success', 'Impressive');

        // Verify that first radio button is no longer checked
        cy.wrap(radio).eq(0).should('not.be.checked');

        // Verify that third button is disabled
        cy.wrap(radio).eq(2).should('be.disabled');
      });
  });
});

Code explanation:

We are visiting our app’s page dedicated for testing radio buttons (page). We are using before hook for that, since we only have 1 test.

Furthermore, we are trying to find all radio buttons on the page, by searching class and type.

Then, we are creating JQuery object, wrapping up all our radio buttons.

We are first selecting the first radio button with cypress function .first() (note: this is the same as if we wrote index .eq(0)). We are forcing this action because another element in the DOM is hovering ours ({ force: true }) and we are verifying that our radio button is checked and expected text is displayed.

Then, we are selecting second radio button with second index .eq(1) and we are performing the same checks as in previous example, except we added now new assertion - to check if previous radio button is not selected any more.

Then, we are verifying that the third radio button is disabled - not clickable.

ℹ️ In real-life projects, it often happens that radio buttons, checkboxes, and similar - don’t have unique IDs. That is why this test was written without utilizing provided IDs, and searching elements by other properties (homework note: you can practice and write this test in another way, try to use provided IDs for radio buttons).

2: Execute the test: Open Cypress CLI and run this test. Have a look at the logs.

Checkbox Actions

Checkbox actions are very similar to radio buttons, except you can choose multiple checkboxes, compared to radio buttons where it is usually a single choice. Let’s try.

Learn more about checkbox actions:
ℹ️ check
ℹ️ uncheck

1: Create a new test file under e2e/elements_manipulation and call it, for example, checkbox.cy.js. Write the following test inside.

/// <reference types="Cypress" />

describe('Checkboxes: Checkbox actions', () => {
  before('Navigate to checkbox page', () => {
    cy.visit('/checkbox');
  });

  it('Check different checkbox actions', () => {
    // Open home dropdown
    cy.get('button[aria-label="Toggle"]').click();

    // Open Desktop dropdown
    cy.get('button[aria-label="Toggle"]').eq(1).click();

    // Get all checkboxes, select Desktop folder and everything under desktop folder.
    cy.get('[type="checkbox"]').then((checkbox) => {
      cy.wrap(checkbox).eq(1).check({ force: true }).should('be.checked');
      // Verify that correct text is displayed for chosen options
      cy.contains('.text-success', 'desktop');
      cy.contains('.text-success', 'notes');
      cy.contains('.text-success', 'commands');

      // Uncheck notes
      cy.wrap(checkbox).eq(2).uncheck({ force: true }).should('not.be.checked');
      cy.contains('.text-success', 'notes').should('not.exist');

      /* Select every checkbox in the tree, uncheck Notes and then select Notes by 
          not specifying exact Notes checkbox index */
      cy.wrap(checkbox).eq(0).check({ force: true }).should('be.checked');
      cy.wrap(checkbox).eq(2).uncheck({ force: true }).should('not.be.checked');

      cy.wrap(checkbox).check({ force: true }).should('be.checked');
      cy.contains('.text-success', 'notes');
    });
  });
});

Code explanation:

We are visiting our app’s page dedicated for testing radio buttons (page). We are using before hook for that, since we only have 1 test.

First, we are clicking on Home arrow element to expand the dropdown tree.

Then we are clicking on Desktop arrow to expand its children.

As you can see in the DOM, these checkboxes we are seeing, don’t have unique IDs. So, we are searching for all elements of type="checkbox" , we are creating JQuery object and then we are wrapping those into single elements we want to use.

First, we are clicking on second checkbox which represents Desktop folder. Then we are clicking on the checkbox to select everything under Desktop folder. We are asserting that parent checkbox of Desktop is checked, and we are asserting that we got text output for Desktop and its children folders - Notes and Commands.

Then, we are unchecking Notes checkbox, we are asserting that it is now unchecked and “notes” output text is not there anymore. For this we used uncheck() function. Why? Because check() function is only to check something, and if you want to uncheck something, you need to use uncheck() or click().

Next, we want to select the entire Home tree and all children checkboxes. But, in order to demonstrate the case when we don’t need specified index for checkbox, let's uncheck Notes (line: 30). On the line 32, you can see that we didn’t specify which checkbox to check next, but you can see that Notes have been checked (line: 32, 33). How did Cypress knew which one to check? Because check() function will always verify all available checkboxes on the page, get their state, and if there is only one left unchecked, it will select that one. If there are more, you will have to specify which one you want to check, as we did in previous examples.

2: Execute the test: Open cypress CLI and run this test. Take a look at the logs.

HOMEWORK:

Add more scenarios that you can think of, for clicking on buttons, filling input fields, checking different checkboxes and radio buttons on the same app pages we used for above explanations.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: button, radio button, input, checkbox tests"

git push

KEEP LEARNING, SEE YOU IN LESSON 6!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 4: Elements, Locators, Assertions

Viktorija Filipov — Fri, 19 May 2023 16:56:21 +0000

DOM Elements

The Document Object Model (DOM) is an essential tool for web interaction, as it creates a virtual representation of a web page loaded in a browser. It serves as a programming interface for HTML and XML documents, allowing web programs to modify the structure, style, and content of the document. The DOM consists of nodes and objects that form the document, enabling programming languages to function on browser pages. Typically, the DOM resides within a browser, while JavaScript serves as the client-scripting language that establishes the necessary connection. JavaScript is responsible for manipulating the DOM in various website operations, such as creating slideshows, validating form submissions, and toggling navigation menus.

To put it simply, any web page you come across is considered a document. Whether you view it as an HTML source or in a browser window, it's essentially a different representation of the same content. The Document Object Model (DOM) allows the webpage to be represented as objects, making it possible to manipulate. By utilizing a scripting language like JavaScript, the document can be modified by targeting these objects.

When examining HTML code, it is crucial to distinguish between various elements, such as tags, attribute names, attribute values, and so on. For instance, let's take the HTML input element structure as an example:

The most helpful tool we will be using to find elements is developer tools, elements inspector in the browser. This is an example HTML DOM structure & element inspection tool (in developer tools of the browser, in this case Chrome).

ℹ️ Elements above the key web element are parent elements.
ℹ️ Elements inside the key web element are child elements.
ℹ️ Elements placed at the same level, side by side, are sibling elements to each other.

Cypress Locators

What are Cypress Locators?

A Selector or Locator is an object that finds and returns web page items/elements on a page based on the query. In Automation, to perform any operation on the web elements first, you need to locate an element and perform an action on that element. The Locator or Selector helps to locate an element in the webpage. There are different types of locators, such as id, CSS, XPath, tag-based selectors, etc.

ℹ️ Cypress supports various locators such as tags, id, class, attributes, text, etc. Cypress also supports XPath Selectors; however, it needs installation of the third-party plugin cypress-xpath. Xpath has not been supported out of the box in the Cypress framework.

To fetch the HTML element in Cypress using different types of locators cy.get() method is used.

Why do we need Locators?

We need Locators in order to manipulate elements on the page, to interact with them as a user would manually do. For example: in order to click on a certain element, or type a text, you have to first locate exactly which element that is on the page.

Giving what we know so far, let’s put this into action.

1: Create another test file under /e2e/intro folder and call it for example locators.cy.js. Write the following code in that file.

/// <reference types="Cypress" />

describe('Locators: Get elements by different locator strategies', () => {
  beforeEach('Navigate to test page', () => {
    cy.visit('/automation-practice-form');
  });

  it('Check different locators strategies', () => {
    // By id
    cy.get('#firstName');

    // By tag name
    cy.get('input');

    // By attribute name
    cy.get('[placeholder]');

    // By attribute name and value
    cy.get('[placeholder="First Name"]');

    // By class name
    cy.get('.col-md-3');

    // By class value
    cy.get('[class="mr-sm-2 form-control"]');

    // By tag name and attribute with value
    cy.get('input[placeholder="First Name"]');

    // By different attributes
    cy.get('[placeholder="First Name"][id="firstName"]');

    // By tag name, attribute with value, ID and class name
    cy.get('input[placeholder="First Name"]#firstName.form-control');

    // // Recommended way - unique attribute + value
    // cy.get('[data-test="first_name"]');
  });

  it('Check finding elements by travelling through DOM', () => {
    // Travel through DOM to find Submit button
    cy.get('#firstName').parents('form').find('button').should('contain', 'Submit');
  });
});

Code explanation:

Before each test we will navigate to the page that we want to test, in this case our practice form link. We opened web element inspector in developer tools, as explained in DOM elements section and we tried to locate different elements of our interest.

In the first test, you can see that we are trying to get elements using different locator strategies using cypress function get(). For some of them, elements found will be unique and for some of them you will see that the cypress has found multiple elements by the locator that we have specified.

It is always the best practice to use UNIQUE locator strategies, such as having a unique attribute for testing (data-test for example), or if that doesn’t exist in the app, you can use id as the second best locator. Often it happens that elements also don’t have IDs, so then you would try to find attributes with unique values or combination of those. Avoid using classes and tags only, as those elements are not unique.

In the second test, you can see one example of how you can travel through DOM to find elements in case that your element doesn’t have any unique value. What we did here is:

We wanted to find Submit button in the form. Let’s pretend that that button doesn’t have any unique element. Next thing we did is - we found one element in the form on the page, that has unique value. We have found its parent - the form, at then inside the form we have found all buttons. Since we need one specific button, we added the assertion that that button should contain text Submit. Note that the text displayed on the page and text that is actually in the DOM can be different, and often is, due to CSS formatting. Always use text that you can see in the DOM, exactly how it is written in the DOM.

2: Let’s run this test in Cypress CLI and see what we will get:

You can see that some elements are unique and others are not. By selecting them, you can see which are those elements exactly inside the app on the right.

You can see that we have found the unique submit button by travelling through the DOM.

🌟 Tips:

You can use element locator inside Cypress CLI tool to find element values. Just click on element selector in the header and pick the element. You can see its value in the header.

You can also use developer tools inside Cypress CLI (element selection, app console logs, network logs etc) :

ℹ️ More about locators:
get
best practices
finding html elements
locators

Assertions

Assertions play a crucial role in automated test cases by verifying the success or failure of specific steps. They serve to validate the desired state of elements, objects, or the application being tested. For example, assertions allow you to confirm whether an element is visible, possesses a specific attribute, CSS class, or state. It is highly recommended that all automated test cases include assertion steps. Without them, it becomes impractical to validate whether the application has achieved the expected state. Cypress incorporates assertions from Chai, Sinon, and jQuery libraries, providing a bundled set of assertion capabilities.

Which are different types of Cypress Assertions?

Cypress integrates multiple assertions from various JS assertion libraries such as Chai, jQuery, etc. We can broadly classify all of these assertions into two segments based on the subject on which we can invoke them:

Implicit Assertions

When the assertion applies to the object provided by the parent chained command, it's called an Implicit assertion. Additionally, this category of assertions generally includes commands such as .should() and .and(). As these commands don't stand independently and always depends on the previously chained parent command, they automatically inherit and acts on the object yielded by the previous command.

Generally, we use Implicit assertions when we want to:

Assert multiple validations about the same subject.
Alter the subject before making the assertions on the subject.

Explicit Assertions

When there is a need to pass an explicit subject for the assertion, it falls under the category of Explicit assertion. This category of assertions contains the commands such as expect() and assert(), which allow you to pass an explicit subject/object.

Generally, You will be using "Explicit assertions" when you want to:

Perform some custom logic before making the assertions on the given subject.
Perform multiple assertions against the same subject after applying custom logic.

The most commonly used assertions are Should and Expect. Assert is not commonly used in e2e test, but rather in unit testing or component testing. Let’s try to write some code and compare two types that are often used in e2e tests:

Add new test to locators.cy.js file and run the test:

  it('Check different types of assetions', () => {
    // Should assertion
    cy.get('[for="gender-radio-2"]')
      .should('contain', 'Female')
      .and('have.class', 'custom-control-label');

    // Expect assertion
    cy.get('[for="gender-radio-2"]').then((element) => {
      expect(element).to.have.text('Female');
      expect(element).to.have.class('custom-control-label');
    });
  });

Code explanation:

These two assertions are testing the same thing - first they will assert that there is an option to choose gender “Female” (it will search for text) in the form and then they will check if that element has class custom-control-label. These are just samples of assertion methods, we will see more of them throughout this workshop. Unless you are dealing with complex JQuery elements and manipulations over them, or API assertions, it is recommended to stick to .should syntax.

ℹ️ More about cypress assertions:

chai
cypress assertions in general

HOMEWORK

Write more tests that will try to locate elements on demoqa page and perform different assertions over those elements (that element is visible, element is not visible, text is visible or not, element contains certain class, check number of found elements on the page (length), etc.

Don’t forget to push everything you did today on Github 😉 Remember git commands?

git add .

git commit -am "add: locators and assertions tests"
git push

YOU’RE DOING AMAZING, SEE YOU IN LESSON 5!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 3: Test structure and test execution

Viktorija Filipov — Sat, 13 May 2023 16:44:31 +0000

LESSON 3: Test structure and test execution

For the purpose of this lesson, we will not go into the explanation of all project folders and files that can be used in Cypress for writing tests, but rather we will focus only on the main test file structure. That being said, main constructs which we majorly use in Cypress test development are:

describe(): It is is simply a way to group our tests. It takes two arguments, the first is the name of the test group, and the second is a callback function. (note: context() is is just an alias for describe()).

it(): We use it for an individual test case. It takes two arguments, a string explaining what the test should do, and a callback function which contains our actual test.

before(): It runs once before all tests in the block.

after(): It runs once after all tests in the block.

beforeEach(): It runs before each test in the block.

afterEach(): It runs after each test in the block.

.only(): To run a specified suite or test, append ".only" to the function.

.skip(): To skip a specified suite or test, append ".skip()" to the function. (you can also put “x” in front of it block to skip it)

✏️ HOMEWORK

Play with test structure and try to guess execution order.

Don’t forget to push everything you did today on Github 😉 Remember git commands? 😉

git add .
git commit -am "add: first test"
git push

CONGRATS ON WRITING YOUR FIRST TEST, AND SEE YOU IN LESSON 4!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 2: Code quality and static analysis

Viktorija Filipov — Fri, 12 May 2023 16:28:12 +0000

LESSON 2: Code quality and static analysis

A Brief Overview

Firstly, we will discuss the purpose of linters. Put simply, a linter is a tool that assists in enhancing your code. While linters are not specific to JavaScript, it is predominantly JavaScript (or similar dynamically-typed languages) that attracts most individuals seeking information about linters. Linter functions as a valuable aid in code improvement. How does it achieve this? By thoroughly analysing your source code to identify any issues.

Now, what exactly is static analysis? Think of it as a form of pre-execution debugging. Static analysis involves utilizing specialized tools that thoroughly examine your source code for errors, deviations from established rules or conventions, and other potential problems.

Benefits of Linting

Reduced production errors: Linters play a crucial role in identifying and resolving technical issues, such as code smells, security issues or typos. This results in fewer defects slipping into the production environment.

Improved code readability, maintainability, and consistency: Linters contribute to achieving a more readable and consistent code style by enforcing specific rules. This helps teams maintain code that is easier to understand and maintain.

Streamlined code review: Linters eliminate lengthy debates over code style and aesthetic choices during code reviews. By adhering to the rules set by the linter, discussions can focus on more critical aspects of the code.

Objective assessment of code quality: Code quality discussions often involve subjective opinions. Linters provide an objective and quantifiable evaluation of code quality, enabling a more data-driven approach.

Enhanced security and performance: While not all linters analyse code for performance and safety, some do. These linters help identify potential security vulnerabilities and performance bottlenecks, resulting in more secure and efficient code.

Increased exposure to code quality education: Linters serve as valuable educational tools, especially for inexperienced developers. They assist in familiarizing developers with code quality standards and best practices, promoting continuous learning and improvement.

Types of Checks Linters Provide

Syntax Errors
Code Standards
Code Smells
Security Checks

Importance of Linters in test automaton

Test automation code is as important as application (development) code itself. It should also follow best coding standards. Without ensuring the quality of test automation code, we can’t assure application code either, since bugs in testing code mean flaky tests, test script bugs, and eventually failure of bug discovery in application code.

Linter installation in workshop project

1: Install ESLint, Prettier and Husky libraries : Open VS terminal and execute following commands one after another.

npm install eslint --save-dev

npm install eslint-config-airbnb --save-dev

npm install eslint-config-prettier --save-dev

npm install eslint-plugin-chai-friendly --save-dev
npm install eslint-plugin-cypress --save-dev
npm install eslint-plugin-import --save-dev
npm install eslint-plugin-jsx-a11y --save-dev
npm install eslint-plugin-prettier --save-dev
npm install eslint-plugin-react --save-dev
npm install husky --save-dev
npm install prettier --save-dev

👀 To read:

What is ESLint? ESLint
What is Prettier? Prettier
What is Husky? Husky
Eslint plugin vs extends: Plugins/Extends

2: Add ESLint and Prettier configuration in project root:

Open your VS terminal and execute the following commands one after another:

touch .eslintrc.json
touch .prettierrc.json
You will see that those two files are created in project root.

Open .eslintrc.json and type the following:

{
    "plugins": [
      "cypress",
      "chai-friendly",
      "prettier"
    ],
    "extends": [
      "airbnb",
      "prettier"
    ],
    "rules": {
      "no-unused-expressions": 0,
      "chai-friendly/no-unused-expressions": 2,
      "cypress/no-force": 0,
      "cypress/no-async-tests": "error",
      "prettier/prettier": ["error"],
      "camelcase": 0,
      "no-plusplus": 0,
      "func-names": 0,
      "class-methods-use-this": 0,
      "no-prototype-builtins": 0,
      "no-restricted-syntax": 0,
      "radix": 0,
      "consistent-return": 0
    },
    "env": {
        "cypress/globals": true
      }
}

Open .prettierrc.json and type following:

{
    "printWidth": 100,
    "singleQuote": true
}

3: Add commands to package.json file

{
  "name": "cypress-workshop",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "cypress-cli": "cypress open",
    "cypress-headed": "cypress run -b chrome",
    "cypress-headless": "cypress run --headless -b chrome",
    "eslint": "eslint cypress",
    "eslint-fix": "eslint cypress --fix"
  },
  "author": "",
  "license": "ISC",
  "husky": {
    "hooks": {
      "pre-commit": "npm run eslint-fix"
    }
  },
  "devDependencies": {
    "cypress": "^10.0.0",
    "eslint": "^8.16.0",
    "eslint-config-airbnb": "^19.0.4",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-chai-friendly": "^0.7.2",
    "eslint-plugin-cypress": "^2.12.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-jsx-a11y": "^6.5.1",
    "eslint-plugin-prettier": "^4.0.0",
    "eslint-plugin-react": "^7.30.0",
    "husky": "^8.0.1",
    "prettier": "^2.6.2"
  }
}

So - now with everything installed and written for linters, every time you want to check your code, you can run in your VS terminal:

npm run eslint
If you discover there are errors, you will see error logs, and you will be able to identify what is wrong in the code. Some errors can be fixed automatically, so if you want to do that, just run:

npm run eslint-fix
and code will be fixed for you automatically.

Make it a habit to check the quality of your code before you push anything to GitHub. If in case you forget, that is why we set up Husky hook. What this will do is prevent you to commit code to GitHub if there are errors. As you can see in package.json we defined which command will be executed when you try to commit something to GitHub "pre-commit": "npm run eslint-fix". ESLint will try to automatically fix your errors and if you had any, you will obviously have a change in code base, which means you have to run

git add .
again, and then try to commit the change again. If you still see errors, that means that those specific errors can’t be fixed automatically, and you will have to change your code manually according to guidance provided in ESLint log.

An example error from ESLint would look something like this:

This is an example where I can’t fix this error by running npm run eslint-fix. I have to go to the file specified in the log and look for my error on line 32.

LESSON 3 PREPARATION:

Please do the following steps to prepare for Lesson 3. These changes are not related to Lesson 2, but we need them for lesson 3.

1: Add error handler under support/e2e.js:

The reason why we need this is because we don’t want that our test execution fail because of console error events in the production application. This is something the people usually decide on the project if they should test or not, but for the purposes of this workshop we won’t bother with application error events in the console.

// Import commands.js using ES2015 syntax:
import './commands';

// Alternatively you can use CommonJS syntax:
// require('./commands')
Cypress.on('uncaught:exception', () => false);

Read more about cypress event types: Link

2: Add Cypress configuration in cypress.config.js file

This is the configuration where we define how would we want Cypress to run our tests, how long to wait on commands, if we want to retry tests if they fail, set the size of runner window etc.

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  defaultCommandTimeout: 5000,
  video: false,
  screenshotOnRunFailure: false,
  chromeWebSecurity: false,
  retries: 3,
  viewportWidth: 1920,
  viewportHeight: 1080,

  e2e: {
    baseUrl: 'https://demoqa.com',
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
});

Config

Learn more about cypress config: Cypress Config

✏️ HOMEWORK:

Read about linters from the above links, and try to understand their purpose. You should be able to tell the purpose of Linters and why it is important to maintain good code quality.

Don’t forget to push everything you did today on Github 😉 Remember git commands? 😉

git add .
git commit -am "add: linter support and cypress configs"
git push

THANK YOU AND SEE YOU SOON IN LESSON No.3!🙌

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Part 1: Introduction and installation

Viktorija Filipov — Fri, 12 May 2023 15:37:05 +0000

LESSON 1: Introduction and installation

1: Install Chrome: Chrome

2: Install Node.js: Node.js

3: Install IDE: Visual Studio Code

4: Set Auto-Save for Visual Studio Code (afterDelay)

5: Install Cypress CLI: Cypress CLI (Click on download Cypress directly from our CDN)

6: Install Git: Git

7: Open GitHub Account: GitHub

8: Create SSH keys: SSH

9: Add SSH keys to your Github Account:

10: Create new folder in your desired location on computer, call it cypress-workshop. That will be your project repository.

11: Open that folder in Visual Studio Code. You should be able to see in left navigation in Visual Studio Code that you entered into your folder - you will see it’s name.

12: Open terminal in Visual Studio Code (VS).

13: In the VS terminal, run:

npm init

14: In the VS terminal, run:

npm install cypress --save-dev

You should be able to see something like this in package.json file:

{
  "name": "cypress-workshop",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "cypress": "^10.0.0"
  }
}

15: In the VS terminal, run:

touch .gitignore

16: Open .gitignore file and type following content. We do not want to push all our files to Github.

.DS_Store
node_modules/
.vscode
cypress/videos/
cypress/screenshots/

✏️ HOMEWORK:

This lesson itself is a homework. Additionally, you can try to research all these tools on their official websites, provided in this document. Try to understand the purpose of these tools.

If you made it this far, here is the Bambi for you:

THANK YOU AND SEE YOU SOON IN LESSON No.2!

Completed code for this lesson

If you have learned something new, feel free to support my work by buying me a coffee ☕

Cypress Workshop Series Announcement

Viktorija Filipov — Fri, 12 May 2023 14:47:16 +0000

In this series, you will learn many useful things related to web UI automation in general, best practices and, of course, all Cypress methods that you will be required to use in real life projects. This will be a course about E2E Cypress testing, for beginners.

Since this is a complex topic that takes years to master, we will not cover every single function or everything related to web UI automation, but you will have a solid base which will give you enough knowledge to independently continue learning the subject. You will see links to official Cypress documentation in every lesson, where you can find more information about what we are covering in this series.

Remember - if you really want to master Web UI Automation, or any test automation for that matter, real life experience is the most important. During and after the workshop, take initiative and try to implement your workshop knowledge on a real life project. Every test will be a new challenge where you will master a new command, new method and doing, so you will dive deeper into test automation, and you will truly become a Ninja!

WORKSHOP PLAN

Introduction and installation
Code quality and static analysis
Test structure and test execution
Elements, Locators, Assertions
Elements manipulation - Button, Input, Radio Button, Checkbox
Elements manipulation - Lists, Date picker
Elements manipulation - Tables, Upload
Elements manipulation - Tooltips, Alerts, Frames
Reusability, Page Object Pattern, Commands
API, Working on different environments
Reporting - Qase, Github Actions

COMPLETE WORKSHOP PROJECT

Link to complete project

LEARNING SOURCES

In order to be a great test automation engineer, you will have to understand various different technologies, not just the test framework - such as Cypress. So, my recommendation for learning resources that will complement this class are:

Learn JavaScript: JavaScript Tutorial (for anyone interested in JS based test frameworks)

Learn HTML: HTML Tutorial

Learn Node.js: Node.js Tutorial (for anyone interested in JS based test frameworks)

Learn about APIs:

What is an API? Full Form, Meaning, Definition, Types & Example

Postman Tutorial for Beginners to perform API Testing

SOAP vs. REST vs. GraphQL: Difference Between Web API Services

Learn about CI/CD:

CI/CD Pipeline: A Gentle Introduction - Semaphore

What is CI/CD? Continuous integration and continuous delivery explained

Learn about Git and Github:

Git Tutorial