Javascript

What is Cypress Studio?

May 3, 2024

5 min read

Introduction

Cypress Studio has been around for some time. It was introduced in Cypress v6.3.0, removed in v10, and reintroduced in v10.7.0. This blog post will dive into its current state and how to use it today.

What is Cypress Studio

Cypress Studio is a tool built on top of Cypress. It offers an interface for creating tests as if you were using your site without requiring code to be written. It adds functionality to query elements and to add assertions from the interface. It's important to note that Cypress Studio is still under an experimental flag and lacks support for Component Testing (another feature of Cypress).

Creating an app to test

We first need a working app because the tool we will use is meant for end-to-end tests. I'll pick Svelte and Vite for this demo, but you can choose any framework. Cypress is agnostic in that matter.

npm create vite@latest cypress-studio-svelte

Make sure to select the Svelte and Typescript options to follow along.

Now open your project location, install dependencies, and start your app to ensure everything works correctly.

cd cypress-studio-svelte
npm i
npm run dev --open

Installing and setting up Cypress Studio

Now it's time to add Cypress to our dev dependencies.

npm i -D cypress

With our dependency installed, let's launch it so we can start configuring it. But first let’s add an entry under scripts in our package.json file.

// ...
    "scripts": {
		// ...
		"cypress": "cypress"
	}
// ...

npm run cypress open

A new window will open that will guide us through the initial setup.

Select the "E2E Testing" option to create the required configuration files. Then, you can close the window. A new folder called cypress and a configuration file cypress.config.ts are created at the root of our project.

To enable Cypress Studio, we must open the newly created configuration file and add the experimentalStudio property.

import { defineConfig } from "cypress";

export default defineConfig({
  e2e: {
	experimentalStudio: true // add this option!
  },
});

For this project, we need to ensure that TypeScript is configured properly for Cypress when it runs, as it conflicts with the one in our root folder. We will extend the original typescript configuration and override some properties. Create a new tsconfig.json file inside the' cypress' folder.

{
    "extends": "../tsconfig.json",
    "include": [
      "../node_modules/cypress",
      "**/*.cy.ts"
    ],
    "exclude": [],
    "compilerOptions": {
      "noEmit": false,
      "sourceMap": false,
      "target": "es5",
      "lib": ["es5", "dom"],
      "types": ["cypress"]
    }
}

You can find more information on setting up TypeScript with Cypress in their documentation

Creating tests

Now that our setup is complete let's write our first test. We will create a folder called e2e and a new test file.

	mkdir cypress/e2e
	touch cypress/e2e/home.cy.ts

Open the new file and create an outline of your tests. Don't add anything to them. I initialized my file with a few tests.

describe("Home Page", () => {
    it("there's a button with a counter",  () => {

    });

    it("when clicking on the counter button, the count increases", ()=> {

    });

    it("when reloading the page, the count is reset to 0", () => {

    });
})

There is an option to create spec files from the interface, but it will contain some initial content that you most likely remove. There’s third option to scaffold multiple specs files, these can serve as a learning resource for writing tests as it contains many different scenarios tested.

Make sure your app is running and, in another terminal, start cypress.

npm run cypress open

Select E2E testing and Chrome. You should now see a list with all your test files.

Click on home.cy.ts. Your tests will run and pass because we have not made any assertions.

This looks the same as if we haven't enabled Studio, but there's a new detail added when you hover on any of the tests: a magic wand that you can click to start recording events and adding assertions directly in the UI.

Let's start with our first tests and check what assertions we can make. The first step is to navigate to a page. This interaction will be recorded and added to the test. To make assertions, right-click on an element and select the ones you want to add.

After we complete our test, let's review our generated code. Go to the test file and see the changes made to it. It should look something like this.

it("there's a button with a counter",  () => {
    /* ==== Generated with Cypress Studio ==== */
    cy.visit('localhost:5173/');
    cy.get('button').should('be.visible');
    cy.get('button').should('be.enabled');
    cy.get('button').should('have.text', 'count is 0');
    /* ==== End Cypress Studio ==== */
});

Cypress Studio will attempt to pick the best selector for the element. In this case, it was able to choose button because it is unique to the page. If there were more buttons, the selector would've been different.

You can interact with elements as if you were using the page regularly. Note that Studio supports a limited set of commands: check, click, select, type, and uncheck.

Let's record our second test and verify that the button will increase its count when clicked.

That was quick. Let's review our generated test.

 it("when clicking on the counter button, the count increases", ()=> {
    /* ==== Generated with Cypress Studio ==== */
    cy.visit('localhost:5173/');
    cy.get('button').should('have.text', 'count is 0');
    cy.get('button').click();
    cy.get('button').should('have.text', 'count is 1');
    cy.get('button').click();
    cy.get('button').should('have.text', 'count is 2');
    cy.get('button').click();
    cy.get('button').should('have.text', 'count is 3');
    /* ==== End Cypress Studio ==== */
});

So far, our tests have been very accurate and didn't need any modifications. However, take Studio as a helper to write tests visually and their selector as suggestions. Let's take the bottom link with the text "SvelteKit" as an example.

It will generate the assertion:

cy.get(':nth-child(4) > .s-XsEmFtvddWTw').should('have.text', 'SvelteKit');

This selector is accurate, but modifying the elements' structure or order would break the tests.

We don’t want tests to break for reasons that do not affect our users. A change in order does not have the same impact for the user as changing the text of a button or changing the url of a link. These selectors should be as specific as possible, but rely as less as possible on implementation details. Selecting images by its alt attribute it’s a way to find a specific element and at the same time ensure that element is accessible. (Accessibility has a direct impact on users)

As a counterpart, when clicking any of the logos above, we will get very interesting selectors (and assertions).

cy.get('[href="https://vitejs.dev"] > .logo').should('have.attr', 'alt', 'Vite Logo');
cy.get('[href="https://svelte.dev"] > .logo').should('have.attr', 'alt', 'Svelte Logo');

With these assertions, we check that our images have an alt attribute set and are tied to a specified link.

Conclusion

As with any other automated tool, check the output and solve any issues that you may find. Results depend on the structure of the page and Cypress Studio's ability to choose an adequate selector. Overall, this tool can still help you write complex tests with plenty of interactions, and you can later modify any selectors. Besides the selector, I found it helpful in writing the assertions. If you’re new to Cypress or e2e testing, it can be of great help to go from an idea to a working test. Reviewing these tests can be a great way to learn how these tests are built.

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.

Ignacio Falk

I love to learn new things and share what I know. Mentor, Writer, Speaker Member of the local community

@flakolefluk @flakolefluk

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

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

Testing with Vitest

Vitest is a new testing framework powered by Vite. It's still in development, and some features may not be ready yet, but it's a nice alternative to try and explore. Setup Let's create a new Vite Project! Note: Vitest requires Vite >=v2.7.10 and Node >=v14 to work. ` With our project created, we now need to install all the dependencies required for Vitest to work. ` I added jsdom to be able to mock the DOM API. By default, Vitest will use the configuration from vite.config.ts. I will add one modification to it, and it's svelte specific. Disabling Svelte's hot module replacement when running tests. It should look like the following: ` I'm using the VITEST env variable to differentiate when running tests, but if your configuration is too different, you can use another configuration file for tests. There are a couple of options to do this. * Create a configuration file named vitest.config.ts: it will take precedence when running tests * Using the --config flag: use it like npx vitest --config Writing tests Let's write some tests for the Counter component created by default with our project. ` To write our first set of tests, let's create a file named Counter.spec.ts next to our component. ` Adding the comment line @vitest-environment jsdom at the top of the file will allow us to mock the DOM APIs for all of the tests in the file. However, doing this in every file can be avoided via the config file. We can also make sure that we import describe, it, expect as globals. We do this via the config file. We need to make the types available by adding vitest/globals types in your tsconfig.json file (you can skip this if not using TypeScript). ` ` Our test files don't need to import globals now, and we can remove the jsdom environment setup. ` Commands There are four commands to run from the cli: * dev: run vitest in development mode * related: runs tests for a list of source files * run: run tests once * watch: default mode, same as running vitest. Watches for changes and then reruns the tests. test/suite modifiers There are modifiers for tests and suites that will change how your tests run. * .only will focus on one or more tests, skipping the rest. For suites, it will focus on all the tests in it. * .skip will skip the specified test/suite. * .todo will mark a test or suite to be implemented later. * .concurrently will run contiguous tests marked as concurrent in parallel. For suites, it will run all tests in it in parallel. This modifier can be combined with the previous ones. For example: it.concurrently.todo("do something async") Assertions Vitest ships with chai and jest compatible assertions ` For a list of available assertions, check the API docs. Coverage For coverage reports, we will need to install c8 and run the tests with the --coverage flag ` This will give us a nice coverage report. An output folder coverage will be created at the root of the project. You can specify the desired output type in the configuration file. ` UI You can also run vitest using a UI, which can help you visualize what tests you are running, and their results. Let's install the required package, and run it with the --ui flag. ` I like this interface. It even allows you to read the test code and open it in your editor. More features Vitest comes with many more features, like snapshot testing, mocking, fake timers, and more that you may know from other testing libraries. Migrating to Vitest (from a Vite project using jest) If you are working on a small project or just starting one, you may need to adapt your config file and that would be it. If you are using mock functions, Vitest uses TinySpy and for fake timers, it uses @sinonjs/fake-timers. Check for compatibility. Also, remember to import {vi} from vitest if you will be using it. Another thing that you may need to configure is a setup file. For example, to use jest-dom matchers, we can create a setup file. ` and declare it on our config file. ` Here is an example of the migration of VitePress to Vitest. (There are some ts-config changes but you can see where vitest is added, and the vitest.config.ts file) Final Thoughts Even though Vitest is still in development, it looks very promising, and the fact that they kept the API so similar to Jest, makes the migration very smooth. It also ships with TypeScript support (no external types package). Using the same config file (by default) lets you focus on writing tests very quickly. I look forward to v1.0.0...

Jan 27, 2022

4 mins

JavaScriptTesting

Maximizing Server Rendering for Interactive Next.js Applications

Maximizing Server Rendering for Interactive Next.js Applications Next.js has come a long way since its inception, and it's now a powerful framework that combines both server-side and client-side rendering. With the introduction of React Server Components (RSCs) and the classic client components, you have the flexibility to create a purely client-rendered app with many client components or a purely server-rendered app using RSCs. However, what if you want to have the best of both worlds? Server rendering improves performance and can deliver much of the HTML quickly, reducing the need for the client to render the entire page. This also results in smaller bundles delivered to the client. The question is, how would you maximize server rendering while still having an interactive application? This blog post will show you how. Building a Lightweight Shopping Experience To illustrate the concept, we'll build a lightweight shopping experience with a list of products and an "Add to Cart" button that opens a drawer with the added cart items. Most of the page will be server-rendered, and we'll use client components only to show the drawer. Even the drawer itself will not be entirely a client component; rather, the wrapper necessary to show the drawer will be a client component, while the contents will be server-rendered. This can be accomplished by the nature of client components that can accept server-rendered content. We'll set up a React context provider at the layout level, which will control showing or hiding the cart. This provider will be used by our client components (the "Add to Cart" button and the "Show Cart" button), as well as by the drawer wrapper. When you click "Add to Cart," this will invoke a server action (more on that later), and then use a function provided through the context of the provider to show the drawer. The Code For this example, we'll use shadcn as our component library. It looks nice, and it also provides a good, accessible component for our cart drawer. Looking at our wireframe above, we'll need a total of three components: - Button - Table - Sheet The components can be installed with a single command: ` Next, we'll set up our React context provider: ` ` The provider provides a boolean flag to indicate whether the cart is currently shown (isCartShown) and a function to change that (setCartShown). Note that CartProvider is a client component, but its contents are provided as children. Therefore, CartProvider is just a thin client-component wrapper around its contents. Now, let's see the implementation of the "Add to Cart" button and the CartDrawer component. The AddToCartButton is a client component that reads the React context and calls its setCartShown function after adding to the cart has been completed. This will, in turn, set the isCartShown flag on the provider and show the cart drawer, which also reads the isCartShown flag from the provider. How is the cart updated, though? We'll use a server action named addToCartAction for that. We'll explain how this works in a bit, but in the meantime, let's see the implementations of the AddToCart button and the CartDrawer component. ` Similar to the CartProvider component, the' CartDrawer' component is a thin client component wrapper around its contents. It reads the React context provided by the CartProvider and passes it to the Sheet component from the Shadcn library. The SheetContent component accepts cart contents as children passed from the CartDrawer's parent, which is server-rendered. ` Using Server Actions and Cache Invalidation But how do we ensure that the contents are updated? The contents are an RSC component called CartContents that calls getCachedCart in the data access layer. In real-world scenarios, getCachedCart would probably call a database or an API, but we have neither here. So, we'll simulate a database through the use of the file-system-db package, a lightweight Node library that can write and read to a JSON file as a database. The get calls to the database are wrapped in unstable_cache, which allows us to tag such requests with cart. This means CartContents is initially fetching data from the tagged getCachedCart call. ` Whenever we mutate the cart, we want to call invalidateTags("cart"). This will force purging of Next.js caches and consequently re-render the cart. For example, the "Add to Cart" button calls the addToCartAction server action, which adds the item to the database and calls invalidateTags("cart"). This server action call returns an updated RSC payload to the client, which re-renders the part that depended on the getCachedCart call - and that is the CartContents component. ` ` And that's it. We now have a fully functional, mostly server-rendered cart, where only small bits of interactivity are modeled as client components. Here is the result: Some of the code shown above remains, such as the "Show Cart" button and the table of products, but those are just UX improvements on top of the core functionality. You can see the entire source code on Stackblitz. Wrapping Up In this blog post, we've explored how to maximize server rendering in Next.js while still having an interactive application. By leveraging React Server Components, client components, and server actions, we've created a shopping experience where most of the page is server-rendered, but the cart drawer is interactive and updates in real time. This approach improves performance, reduces the client-side rendering burden, and delivers smaller bundles to the client....

May 15, 2024

5 mins

NextJS

What is Cypress Studio?

Introduction

What is Cypress Studio

Creating an app to test

Installing and setting up Cypress Studio

Creating tests

Conclusion

Ignacio Falk

You might also like

How to test React custom hooks and components with Vitest

Does Replay Fix All Debugging Issues?

Testing with Vitest

Maximizing Server Rendering for Interactive Next.js Applications

You might also like

How to test React custom hooks and components with Vitest

Does Replay Fix All Debugging Issues?

Testing with Vitest

Maximizing Server Rendering for Interactive Next.js Applications

Introduction

What is Cypress Studio

Creating an app to test

Installing and setting up Cypress Studio

Creating tests

Conclusion

Ignacio Falk

How to test React custom hooks and components with Vitest

Does Replay Fix All ​​Debugging Issues?

Testing with Vitest

Maximizing Server Rendering for Interactive Next.js Applications

How to test React custom hooks and components with Vitest

Does Replay Fix All ​​Debugging Issues?

Testing with Vitest

Maximizing Server Rendering for Interactive Next.js Applications

Does Replay Fix All Debugging Issues?

Does Replay Fix All Debugging Issues?