What is Cypress Test Suite?

A test suite is a collection of test cases that is used to execute tests and report on their results. You can have a test suite for any of the essential features of a software application or for a particular kind, such as smoke, security test suites, and many more.

A test suite is a collection of test cases that is used to execute tests and report on their results. You can have a test suite for any of the essential features of a software application or for a particular kind, such as smoke, security test suites, and many more. 

Table of Contents

What is a Cypress Test Suite? 

The Cypress method of grouping multiple related tests is called describe. Each describe block belongs to a set of tests. 

We enclose each new set of tests we create for functionality in a ‘describe’ block before we begin writing them.

describe("Test suite", () => { ... ... });

As we can see, the describe block requires two arguments: a callback function to wrap the actual test and a string to describe the test suite.

Test Case

Using it block, a test case may be created. There may be one or more test cases in a test suite. A test suite may include both positive and negative test cases for a functionality. Because of this, a describe may contain one or more it blocks.

describe("Test suite", () => { beforeEach(() => { .... }); afterEach(() => { .... }) it("test case", () => { ..... }); });

Conventions for describe and it block

  • A describe block’s description must begin in uppercase.
  • The describe block’s description should be succinct.
  • Prevent using lengthy or “should” sentences in the description block.
  • The functionality name alone may be sufficient.

For instance, the describe block should seem as follows if we are testing the “signup” functionality:

describe("Signup", () => { ... ... });

The describe block should seem as follows if we are testing the “login” functionality:

// Incorrect describe("Verify login functionality", () => { ... ... }); // Correct describe("Login", () => { ... ... }); 
  • it block descriptions must always be written in lowercase.
  • it block’s description could be more specific.
  • The description might either begin with should or must. However, it’s not necessary to begin with these terms, just make sure it makes sense.

Prevent using ambiguous or generic descriptions.

//Incorrect it("should verify customer", () => { .. ... }); 

Developing the first Test Case in Cypress

Consider the Cypress test automation scenario below

  • Open the URL https://www.browserstack.com/
  • Click “SignUp” at the top.
  • Enter the username
  • Enter Password.
  • Select the “Sign Up” button.
  • Automate the above-mentioned scenario:

    ///<reference types="cypress" /> describe('My First Test Suite', function(){ it('My First Test Case', function(){ cy.visit("https://www.browserstack.com/index.html") cy.wait(3000) cy.get("#signin2").click() cy.wait(2000) cy.get("#sign-username").type("code2test") cy.get("#sign-password").type("Password") cy.get("button[onclick='register()']").click() }) })

    The next step is to launch Cypress Test Runner by typing the following command on the terminal. 

    This command will launch the Cypress Test Runner window.

    node_modules\.bin\cypress open

    In the Cypress Test Runner box, we can see that our specification file (FirstTest.js) is there. Choosing a browser now comes from the top-right list box with three choices (Chrome, Firefox, Edge, Electron)

    Let’s say we chose Chrome; next, double-click the FirstTest.js file to begin execution.

    Run Test Execution through the Command line or Terminal

    The commands to run execution from a terminal or without launching Cypress Test Runner are listed below.

    Type the command below to execute a specific test file through the terminal on the default browser.

    node_modules\.bin\cypress run --spec "cypress/integration/2-advanced-examples/FirstTest.js"

    This command will just run the “FirstTest.js” file, and it will execute in the default browser in headless mode (means no browser is visible to you).

    Use the command below to run a full test using all test files present in the example folder.

    node_modules\.bin\cypress run

    For carrying out certain tests on the headed browser (Browser is visible to screen). Hit the command below.

    node_modules\.bin\cypress run --headed --spec "cypress/integration/2-advanced-examples/FirstTest.js"

    Running on several browsers in accordance with requirements. Click the command below.

    node_modules\.bin\cypress run --browser chrome --headed --spec "cypress/integration/2-advanced-examples/FirstTest.js"

    What is a Cypress Test Runner?

    The Test Runner is a key component of the Cypress tool and is necessary for the successful execution of tests. It helps in giving the test case execution its initial push. All commands are tracked and shown in Cypress Runner while test cases are executed in Cypress. 

    This allows for testing in various scenarios.

    Or use this command:

     node_modules\.bin\cypress open

    The degree of visual input and involvement is a major benefit and the main justification for my recommendation for beginners.

    Another testing framework’s drawback is that:

    • Writing tests seems different from writing front-end code as normal.
    • While you’re used to checking the browser for feedback, all of the output is in the terminal.
    • Debugging involves a very distinct process. 

    Test Structure

    Adapted from Mocha, the test interface offers the describe(), context(), it(), and specify(). Choose whatever terminology suits you the most as context() is identical to describe() and specify() is identical to it().

    // -- Start: Our Application Code -- function add(a, b) { return a + b } function subtract(a, b) { return a - b } function divide(a, b) { return a / b } function multiply(a, b) { return a * b } // -- End: Our Application Code -- // -- Start: Our Cypress Tests -- describe('Unit test our math functions', () => { context('math', () => { it('can add numbers', () => { expect(add(1, 2)).to.eq(3) }) it('can subtract numbers', () => { expect(subtract(5, 12)).to.eq(-7) }) specify('can divide numbers', () => { expect(divide(27, 9)).to.eq(3) }) specify('can multiply numbers', () => { expect(multiply(5, 4)).to.eq(20) }) }) }) // -- End: Our Cypress Tests --

    Hooks

    Moreover, Cypress provides hooks (borrowed from Mocha).These are useful for creating pre-test conditions that should be executed before a group of tests or before each test individually. 

    Additionally, they are useful for cleaning up conditions after a series of tests or each test.

    before(() => { // root-level hook // runs once before all tests }) beforeEach(() => { // root-level hook // runs before every test block }) afterEach(() => { // runs after each test block }) after(() => { // runs once all tests are done }) describe('Hooks', () => { before(() => { // runs once before all tests in the block }) beforeEach(() => { // runs before each test in the block }) afterEach(() => { // runs after each test in the block }) after(() => { // runs once after all tests in the block }) }) 

    Excluding and Including Tests

    Using the .only and .skip functions is the simplest approach to skip or filter a test. They may be used to combine several tests into a single specification, allowing you to execute only the tests you need. 

    Only tests 1 and 3 will be executed by this code.

    it.only('test #1', () => { // ... }) it('test #2', () => { // ... }) it.only('test #3', () => { // ... })

    This test will only execute Test 1.

    it('test #1', () => { // ... }) it.skip('test #2', () => { // ... }) it. skip('test #2', () => { // ... })

    These work perfectly whether you use GUI or CI. By the way, to prevent unintentionally leaving  .only in your test, make sure you build up a pre-commit hook that will stop this, or just install this excellent plugin

    These terms can be used in your describe blocks as well. In such instances, testing will work as follows:

    describe.only('suite #1', () => { it('test #1', () => { // this test will run }); }) describe('suite #2', () => { it('test #2', () => { // this test will not run }) }) 

    Different ways to create Cypress Test Suites

    1. Run Multiple tests using Cypress command line’s –spec options

    Consider that we have 3 test files for Cypress. Now, if you wanted to put all of these Cypress test files together and run them as a Test Suite, you can do so by using the –spec option in the command line, as seen in the code below.

    npx cypress run --spec "cypress/integration/one.spec.js, cypress/integration/two.spec.js,cypress/integration/three.spec.js"

    Or, create a simple pacakge.json file shortcut.

    In package.json:

    "cy:run:smoke":"cypress rn --spec=cypress/integration/one.sepc.ts,cypress/integration/two.spec.ts",

    The issue with this strategy is that it becomes complicated when we wish to have several test suites.

    2. Create a Test Suite by grouping the Cypress Tests in a folder

    The second approach is to make subdirectories inside the integration folder, as seen in the following example:

    CypressTypescript -cypress --integration ---home ---profile ---search

    When you’re finished, use the–spec option below to just run the Cypress tests inside your folder:

    npx cypress run --spec "cypress/integration/home/*.spec.js" Or npx cypress run --spec "cypress/integration/home/*"

    3. Creating Cypress test suite using support/index.js & environment variables

    By setting values for environment variables, we may execute Cypress tests in a group or test suite dynamically using this approach, which configures the Cypress support/index.js file and environment variables.

    Therefore, utilizing Environment Variables, you may use this option to dynamically select and run a set of tests in Cypress.

    Here is how to go about it:

    Access the cypress folder from your project root folder > open the support folder > open the index.js file.

    Put the following code in support/index.js:

    beforeEach(function() { let testSuite = Cypress.env('SUITE'); if (!testSuite) { return; } const testName = Cypress.mocha.getRunner().test.fullTitle(); testSuite = "<"+testSuite+">" if (!testName.includes(testSuite)) { this.skip(); } })

    The answer is simple in this case; we are just taking the value of the SUITE environment variable and determining whether it matches any of our tests, such as the description in the describe() or it() blocks.

    Let’s now look at how we may provide the right values in the specifications.

    Change the values in the describe/it function as necessary to match the suite name:

    one.spec.ts //one.spec.ts describe('First Test <home>', () => { //home is suite name it('Test 1', () => { //some code }) }) two.spec.ts //two.spec.ts describe('Second Test <home> <smoke>', () => { //two suites home and smoke it('Test 2', () => { //some code }) }) three.spec.ts //three.spec.ts describe('Third Test <smoke>', () => { //smoke is suite name it('Test 3', () => { //some code }) }) 

    Look at the example from above. The suite name is specified in <> at the end of the describe() statement. Therefore, beforeAll() in support/index.js verifies the value of the SUITE variable before executing.

    For instance, if we give “home” as the value of SUITE, It checks to make sure that <home> exists in the describe function value, or that it does not exist. 

    Either it will execute the test, or it won’t.

    You must provide the suite name in the command line while running tests:

    npx cypress run --env SUITE=smoke

    Because smoke is specified in the line above, only two.spec.js and three.spec.js are executed.  Since there is no <smoke> at the end of the first.spec.ts, it will be skipped.

    Closing Notes

    • Users may view the step-by-step test command execution and its outcome simultaneously when Cypress executes the tests in an interactive way. 
    • With Cypress, it is incredibly simple and quick to build up tests and execute them. Compared to other frameworks, it takes less time to start creating tests.
    • Any CI tool may be integrated, and headless execution with command-line options is possible. 
    • It automatically takes screenshots of a failed test while it is being run. That means it is especially useful when troubleshooting and debugging issues.

    For running, scaling, and debugging your tests, BrowserStack Automate provides the necessary infrastructure for different Cypress versions

    And also, you get the following capabilities

    Test on BrowserStack

    ncG1vNJzZmivp6x7o77OsKqeqqOprqS3jZympmeXqralsY6csKmqlajAbsDErKtmq6WewaY%3D

     Share!