Javascript

How to Create Better Test Coverage Using Cypress 10

Dec 19, 2022

6 min read

Testing is an integral part of software development, and it is important that all developers learn best testing practices. Jordan Powell, DX engineer at Cypress and Angular Google Developer Expert, has some tips to share with developers on how to write better tests using Cypress 10.

In this article, we will take a look at Powell’s tips for writing end-to-end tests, component tests, and advanced testing patterns in Cypress. If you want to learn more from Jordan Powell, please check out his Advanced Cypress JS Drop training.

Why is Testing important?
Types of Testing
A new take on the testing pyramid
Differences between end-to-end testing and component testing
Jordan Powell’s best practices for E2E testing
Jordan Powell’s Best Practices for Component Testing
Jordan Powell’s Advanced Cypress Patterns
- Session
- Origin
Conclusion

Why is Testing important?

Software testing identifies issues within the application, and helps ensure that only high quality products are shipped to the user.

Here are Jordan Powell’s reasons on why testing is important, and how it helps developers:

Documentation: Good testing coverage will result in developers creating stronger test plans and better QA testing for new releases.

Confidence: Writing good tests allows developers to build new features in confidence because the applications are working as intended.

Safe Refactoring: Good test coverage leads to less refactoring down the road, and provides developers more time to work on new features.

Improved UX: Good test coverage provides better UX (User Experience) for the end user because the application is working as intended.

Types of Testing

E2E, Integration, and Unit testing are three common methods for testing software applications.

Unit Test: Unit testing serves as the foundation of the test pyramid. If you're working in a functional language, a unit will most likely be a single function. Your unit tests will call a function with different parameters and ensure that it returns the expected values. In an object-oriented language, a unit can range from a single method to an entire class.

Integration test: Integration testing is where individual components of your application are tested as a group.

End-to-end testing: E2E Testing is a technique that tests your app from the web browser through to the back end of your application, as well as testing integrations with third-party APIs and services. These types of tests are great at making sure your entire app is functioning as a cohesive whole.

A new take on the testing pyramid

In Jordan Powell’s Advanced Cypress JS Drop training, he challenges developers to rethink the traditional testing pyramid, and believes that component testing should also be included.

Component Testing with Cypress 10 allows developers to test individual components quickly, regardless of its complexity. Component tests differ from end-to-end tests in that instead of visiting a URL to pull up an entire app, a component can be "mounted" and tested on its own.

Differences between end-to-end testing and component testing

Here are a few key differences between End-to-end and component testing:

End-to-end testing	Component testing
The entire application and all of its layers are tested	Only the independent components are tested
Testing can be done by developers and QA Teams	Testing is done by the developers
Often requires a complex setup	No extra configuration for CI(Continuous Integration) environments needed
Initialization command: `cy.visit(url)`	Initialization command: `cy.mount(<MyComponent>)`

Jordan Powell’s best practices for E2E testing

Don’t use HTML Native selectors

It is not good practice to use element selectors, id attributes, or class attributes when writing End-to-end tests. Using HTML Native selectors can lead to team members refactoring tests later on, or changing attributes which could affect the tests.

Jordan Powell recommends using data attributes that can inform the team that this is a test attribute. When other team members need to change anything, they will be aware of the function of the attribute and what it may affect.

Use Closures

Jordan warns against assigned return values for Cypress assertions, and recommends using closures to access the Commands yield like this:

cy.get('button').then((btn) => {
    // store the button's
    const txt = btn.text()

    // submit a form
    cy.get('form').submit()

    // compare the two button's text
    // and make sure they are different

    cy.get('button').should((btn2) => {
        expect(btn2.text()).not.to.eq(txt)
    })
})

// these commands run after all of the
// other previous commands have finished
cy.get(...).find(...).should(...)

Independent Test

It is not good practice to combine related tests. Jordan Powell suggests that tests should be run independently from one another without sharing or relying on other test states. If test suites are related in any way, run the related properties or methods before each of the test runs, like in the code below:

describe('my form', () => {
    beforeEach(() => {
        cy.visit('/users/new')
        cy.get('#firstname').type('Hassan')
        cy.get('#lastname').type('Sani')
    })

    it('display form validation', () => {
        // clear out the first name
        cy.get('#firstname').clear()
        cy.get('form').submit()
        cy.get('#errors').should('contain', 'First name is required’)
    })

    it('can submit a valid form', () => {
        cy.get('form').submit()
    })
})

Use Route Aliases

Another recommended practice is to use route aliases to guard Cypress against proceeding until an explicit condition is met.

// route aliases
cy.intercept('**/api/users').as('usersRequest')
cy.wait('@usersRequest')

// assertions
cy.get('button').click()
cy.wait(4000) // <- this is unnecessary
cy.get('p').contains('hello world')

Setting a Global baseUrl

It is bad practice to use hardcoded URL strings for the baseUrl because it will eventually fail when the environment changes. Instead, Powell recommends using a config file that holds the environment baseUrl.

Jordan Powell’s Best Practices for Component Testing

All of the code examples in this next section will be for Angular, but Cypress component testing works for all major Frontend JavaScript frameworks.

Default Config Mount

Component testing takes two parameters: the component to mount, and the object for configuration.

A Custom Mount Config can boost flexibility. It ships a default mount config which you can use, but to manage multiple modules and import without adding too many boilerplate codes, it is recommended to have a custom mount config for specific instances.

import { HttpClientModule } from '@angular/common/http';
import { SharedModule } from 'libs/shared/shared';
import { mount } from 'cypress/angular';

type MountParams = Parameters<typeof mount>

Cypress.Commands.add('mount', (component: MountParams[0], config: MountParams[1] = {}) => {
  return mount(component, {
    ...config,
    imports: [
      ...config.imports,
      HttpClientModule,
      SharedModule
    ]
  })
})

Cypress Intercept

Component testing handles the individual components you are testing at a particular time, to access external API it is recommended to use cy.intercept. According to the Doc Cy.intercept can be used to passively listen for matching routes without manipulating the request or its response in any way.

it('should show bad login message when credentials are invalid', () => {
  cy.intercept('POST', '/auth', {
    statusCode: 401,
  });

  cy.mount('<app-login-form></app-login-form>');
  cy.get('button').contains('Sign in').click();

  cy.get('input[type=email]').type('bad@email.com');
  cy.get('input[type=password]').type('badpass');
  cy.get('button').contains('Sign in').click();

  cy.contains('Invalid username or password');
});

Use createOutputSpy

When working with eventEmitter for components that may contain forms or other elements with events, createOutputSpy will automatically create an EventEmitter and set up the spy on it's .emit() method.

it('should show bad login message when credentials are invalid', () => {
  cy.intercept('POST', '/auth', {
    statusCode: 401,
  });

  cy.mount('<app-login-form></app-login-form>',
     componentProperties: {
       onLogin: createOutputSpy('onLoginSpy'),
     }
   );
  cy.get('button').contains('Sign in').click();

  cy.get('input[type=email]').type('bad@email.com');
  cy.get('input[type=password]').type('badpass');
  cy.get('button').contains('Sign in').click();

  cy.contains('Invalid username or password');
});

Jordan Powell’s Advanced Cypress Patterns

Session

When testing for routes or components that require authentication Cypress provides cy.session which eliminates creating functions in your test to check for sessions on every call to the route or component. cy.session caches the sessions, and it will skip the login process for testing components that need the sessions on a second call.

Cypress.Command.add("login", (username, password) => {
    cy.session(
        [username, password],
        () => {
            cy.request({
                method: 'POST',
                url: '/login',
                body: {username, password},
            }).then(({body}) => {
                window.localStorage.setItem('authToken', body.token)
            })
        }
        {
            validate() {
                cy.request('/whoami').its('status').should('eq', 200)
            }
        }
    )
})

Origin

Running tests for projects that require a visit to multiple different domains could get CORS, or a limitation of visits, due to browser environment. Cypress provides Origin to help bypass some of the browser limitations.

const sentArgs = { username: 'username', password: 'password@254' }
cy.origin(
    'supersecuredsite.com',
    // Send the args here...
    { args: sentArgs },
    // ...and receive them at the other end here!
    ({username, password}) => {
        cy.visit('/login')
        cy.get('input#username').type(username)
        cy.get('input#password').type(password)
        cy.contains('button', 'Login').click()
    }
)

Conclusion

In this article, we looked at Jordan Powell’s tips for writing End-to-end tests, component tests, and advanced testing patterns in Cypress.

I recommend watching the full video for Jordan Powell’s Advanced Cypress JS Drop training.

Are you excited about the Cypress Component Testing? Let us know on Twitter.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Hassan Sani

@inidaname @inidaname

Does Replay Fix All Debugging Issues?

Rob Ocel and Adam Barrett talk with Jason Laster, CEO and co-founder of Replay. For those of you who are unfamiliar, Replay is an innovative browser development tool that is revolutionizing the way developers approach time travel debugging and bug fixing. This episode highlights all the reasons why Replay is such an amazing tool and all the problems it solves for developers. Jason shares the background on where the concept of time travel debugging came from, and how it actually works in Replay. The idea that you can capture a bug once and replay it as many times as needed enables developers to zoom in and identify the root cause of the issue. This approach saves infinite time, as you no longer have to rely on guesswork or spend hours reproducing bugs. Download this podcast episode here!...

Jan 5, 2024

1 min

ReactTesting

How to test React custom hooks and components with Vitest

Introduction In this guide, we'll navigate through the process of testing React hooks and components using Vitest—a powerful JavaScript unit testing framework. Discover how Vitest simplifies testing setups, providing an optimal solution for both Vite-powered projects and beyond. Vitest is a javascript unit testing framework that aims to position itself as the Test Runner of choice for Vite projects and as a solid alternative even for projects not using Vite. Vitest was built primarily for Vite-powered projects, to help reduce the complexity of setting up testing with other testing frameworks like Jest. Vitest uses the same configuration of your App (through vite.config.js), sharing a common transformation pipeline during dev, build, and test time. Prerequisites This article assumes a solid understanding of React and frontend unit testing. Familiarity with tools like React Testing Library and JSDOM will enhance your grasp of the testing process with Vitest. Installation and configuration Let’s see how we can use Vitest for testing React custom hooks and components. But first, we will need to create a new project with Vite! If you already have an existing project, you can skip this step. ` Follow the prompts to create a new React project successfully. For testing, we need the following dependencies installed: Vitest as the unit testing framework JSDOM as the DOM environment for running our tests React Testing Library as the React testing utilities. To do so, we run the following command: ` Once we have those packages installed, we need to configure the vite.config.js file to run tests. By default, some of the extra configs we need to set up Vitest are not available in the Vite config types, so we will need the vite.config.ts file to reference Vitest types by adding /// reference types=”vitest” /> at the top of the file. Add the following code to the vite.config.ts ` We set globals to true because, by default, Vitest does not provide global APIs for explicitness. So with this set to true, we can use keywords like describe, test and it without needing to import them. To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json. ` The environment property tells Vitest which environment to run the test. We are using jsdom as the environment. The root property tells Vitest the root folder from where it should start looking for test files. We should add a script for running the test in package.json ` With all that configured, we can now start writing unit tests for customs hooks and React components. Writing test for custom hooks Let’s write a test for a simple useCounter hook that takes an initial value and returns the value, an increment function and a decrement function. ` We can write a test to check the default return values of the hook for value as below: ` To test if the hook works when we increment the value, we can use the act() method from @testing-library/react to simulate the increment function, as shown in the below test case: ` Kindly Note that you can't destructure the reactive properties of the result.current instance, or they will lose their reactivity. Testing hooks with asynchronous logic Now let’s test a more complex logic that contains asynchronous logic. Let’s write a useProducts hook that fetches data from an external api and return that value ` Now, let’s see what the test looks like: ` In the above example, we had to spy on the global fetch API, so that we can mock its return value. We wrapped that inside a beforeAll so that this runs before any test in this file. Then we added an afterAll method and called the mockRestore() to run after all test cases have been completed and return all mock implementations to their original function. We can also use the mockClear() method to clear all the mock's information, such as the number of calls and the mock's results. This method is handy when mocking the same function with different return values for different tests. We usually use mockClear() in beforeEach() or afterEach() methods to ensure our test is isolated completely. Then in our test case, we used a waitFor(), to wait for the return value to be resolved. Writing test for components Like Jest, Vitest provides assertion methods (matchers) to use with the expect methods for asserting values, but to test DOM elements easily, we will need to make use of custom matchers such as toBeInTheDocument() or toHaveTextContent(). Luckily the Vitest API is mostly compatible with the Jest API, making it possible to reuse many tools originally built for Jest. For such methods, we can install the @testing-library/jest-dom package and extend the expect method from Vitest to include the assertion methods in matchers from this package. ` After installing the jest-dom testing library package, create a file named vitest-setup.ts on the root of the project and import the following into the project to extend js-dom custom matchers: ` Since we are using typescript, we also need to include our setup file in our tsconfig.json: ` In vite.config.ts, we need to add the vitest-setup.ts file to the test.setupFiles field: ` Now let’s test the Products.tsx component: ` We start by spying and mocking the useProducts hook with vi.spyOn() method from Vitest: ` Now, we render the Products component using the render method from @testing-library/react and assert that the component renders the list of products as expected and also the product has the title as follows: ` In the above code, we use the render method from @testing-library/react to render the component and this returns some useful methods we can use to extract information from the component like getByTestId and getByText. The getByTestId method will retrieve the element whose data-testid attribute value equals product-list, and we can then assert its children to equal the length of our mocked items array. Using data-testid attribute values is a good practice for identifying a DOM element for testing purposes and avoiding affecting the component's implementation in production and tests. We also used the getByText method to find a text in the rendered component. We were able to call the toBeInTheDocument() because we extended the matchers to work with Vitest earlier. Here is what the full test looks like: ` Conclusion In this article, we delved into the world of testing React hooks and components using Vitest, a versatile JavaScript unit testing framework. We walked through the installation and configuration process, ensuring compatibility with React, JSDOM, and React Testing Library. The comprehensive guide covered writing tests for custom hooks, including handling asynchronous logic, and testing React components, leveraging custom matchers for DOM assertions. By adopting Vitest, developers can streamline the testing process for their React applications, whether powered by Vite or not. The framework's seamless integration with Vite projects simplifies the setup, reducing the complexities associated with other testing tools like Jest....

Mar 15, 2024

5 mins

ViteReactTesting

Using a Starter Kit on Starter.dev to Kickstart Your React and Angular Projects

As a developer, deciding on the stack to use and the dependencies can be a difficult choice. Once you start, configuration, installation, and making sure you have the correct versions are also chores. Starting with a prebuilt framework for some of these tasks can boost a developer's productivity and save time by eliminating repetitions. In this article, I will walk you through how you can cut 40 hours of setup and boost productivity by focusing on what really matters. We will learn a simple solution for implementing project functionality without worrying about setting up different versions of dependencies and configurations, or repeating the same process for different projects. Introducing Starter Kits starter.dev has a curated list of starter kits for various frameworks and libraries to help boost developer productivity. Why starter kits? Our architects discovered they were repeatedly going through the same process every time they needed to start a new project. This process included initializing, installing dependencies, setting up tests, and everything else that comes with bootstrapping a new project. How to use a Starter Kit Let’s walk through starting apps with Angular, and React with starter kits using the Starter Kits Showcases. Every starter kit is structured with the basic requirements to initialize the projects with key features: - Routing - Forms - State Management - API interactions - REST & GraphQL - Authentication - Test Runners These features help developers understand how to architect and build large scale applications. The default project directories are scaffolded with added directories, configurations, and a demo app to help quickly build or modify the components. Using the Angular Apollo TailwindCSS Starter Kit Every starter kit is easy to initialize so you can start building features for your project. The Angular starter kit sets you up with these tools to quickly get you started: - Angular 13: for build frontend components - Apollo Client: for managing both local and remote data with GraphQL - TailwindCSS: for styling components and elements - Storybook: Component library - Jest: Test runner Initializing the project: To initialize a project with the starter kits, run the following: 1. Run npx @this-dot/create-starter to run the scaffolding tool 2. Select Angular, Apollo, and TailwindCSS kits from the CLI library options 3. Name your project 4. cd into your project directory, install dependencies using the tool of your choice, and voila! You can start building features in your new project immediately. Configurations The project pre-configuration is the recommended Angular GraphQL configuration. The ApolloModule and ApolloClientOptions are imported for the App NgModule. ` ` Project Implementation. Starter kits aim to make your project set up fast, easy and reusable. The initial demo project is a counter example connected to a GraphQL module with a fetch example and routes implemented - all following industry’s best practices. Go ahead to add more components or modify existing components without the need to make any changes to the configuration. Extras The preconfigured Storybook for component management gives developers the opportunity to create organized UI systems making both the building process and documentation more efficient and easier to use. React RxJs and Styled Components The React starter kit tools scaffold to quickly get you started with a React project, and include: - React 17: for building frontend components - RxJs: for managing data - Styled Components: for styling components and elements - React Router: For matching project routes - Storybook: Component library - Jest: Test runner Initializing the project: To initialize a project with the starter kits, run the following: - Run npx @this-dot/create-starter to run the scaffolding tool - Select Create React App, RxJS and Styled Components kits from the CLI library options - Name your project - cd into your project directory, install dependencies using the tool of your choice, and voila! You can start building features in your new project immediately. Configurations The project configuration is the same with an initial create-react-app config boilerplate, but with pre-configurations for Storybook and style component. Conclusion In this article, you were able to boost productivity by cutting the time of setting up and moving straight to implementing components, allowing you to focus on working on what matters. I hope this article was helpful, let us know what other starter kits you will love to see on starter.dev....

Dec 12, 2022

3 mins

AngularReact

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Rob Ocel and Jerome Hardaway continue their series on AI adoption by exploring the world of AI, focusing on small language models (SLMs) and large language models (LLMs). They compare the unique capabilities of SLMs against the vast knowledge encompassed by LLMs, and highlight the transformative potential of AI in driving creativity, problem-solving, and user-centric design in technology. SLMs are designed to excel at specific tasks, offering faster processing and cost-effectiveness due to their open-source nature. These models have proven to be invaluable in sectors like finance, where data security is of utmost importance. By leveraging SLMs, organizations can enhance their security measures and protect sensitive information. Moreover, SLMs provide a stepping stone for engineers to adapt to new technologies and incorporate AI into their work, ultimately improving user experiences. On the other hand, LLMs encompass a wide range of knowledge, making them incredibly versatile. These models have the potential to transform industries by providing insights, predictions, and solutions to complex problems. With advancements in AI chip technology by tech giants like Apple, Nvidia, Google, and Meta, LLMs are becoming even more powerful and efficient. Evaluating AI models based on factors like stability and industry support is crucial to harnessing the full potential of LLMs. The conversation also addresses some ethical questions related to AI implementation. While AI brings numerous benefits, concerns about job displacement cannot be ignored. As AI continues to evolve, it is essential to strike a balance between automation and human involvement. Engineers must focus on improving AI sophistication and seamless integration into user interactions, ensuring that AI enhances human capabilities rather than replacing them. Additionally, ethical guidelines and regulations must be established to address potential biases and ensure responsible AI implementation. Download this episode here....

Apr 23, 2024

2 mins

Engineering Leadership

How to Create Better Test Coverage Using Cypress 10

Table of Contents

Why is Testing important?

Types of Testing

A new take on the testing pyramid

Differences between end-to-end testing and component testing

Jordan Powell’s best practices for E2E testing

Don’t use HTML Native selectors

Use Closures

Independent Test

Use Route Aliases

Setting a Global baseUrl

Jordan Powell’s Best Practices for Component Testing

Default Config Mount

Cypress Intercept

Use createOutputSpy

Jordan Powell’s Advanced Cypress Patterns

Session

Origin

Conclusion

Hassan Sani

You might also like

Does Replay Fix All Debugging Issues?

How to test React custom hooks and components with Vitest

Using a Starter Kit on Starter.dev to Kickstart Your React and Angular Projects

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

You might also like

Does Replay Fix All Debugging Issues?

How to test React custom hooks and components with Vitest

Using a Starter Kit on Starter.dev to Kickstart Your React and Angular Projects

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Table of Contents

Why is Testing important?

Types of Testing

A new take on the testing pyramid

Differences between end-to-end testing and component testing

Jordan Powell’s best practices for E2E testing

Don’t use HTML Native selectors

Use Closures

Independent Test

Use Route Aliases

Setting a Global baseUrl

Jordan Powell’s Best Practices for Component Testing

Default Config Mount

Cypress Intercept

Use createOutputSpy

Jordan Powell’s Advanced Cypress Patterns

Session

Origin

Conclusion

Hassan Sani

Does Replay Fix All ​​Debugging Issues?

How to test React custom hooks and components with Vitest

Using a Starter Kit on Starter.dev to Kickstart Your React and Angular Projects

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Does Replay Fix All ​​Debugging Issues?

How to test React custom hooks and components with Vitest

Using a Starter Kit on Starter.dev to Kickstart Your React and Angular Projects

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Does Replay Fix All Debugging Issues?

Does Replay Fix All Debugging Issues?