Javascript

What is Cypress Studio?

Published May 3, 2024

Updated 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.

About the author(s)

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

A Look at Playwright Parallelism

A Look at Playwright Parallelism Playwright is an open-source automation library developed by Microsoft, designed for testing web applications across multiple browsers. It enables developers and testers to write scripts that simulate real user actions when interacting with web pages. Playwright supports major browsers like Chrome, Firefox, and Safari, including their headless modes. Recently, it has gained a lot of popularity for its robustness, ease of use, and cross-browser compatibility. In this blog post, we will take a look at one very useful aspect of Playwright: running tests in parallel. Parallelism in Playwright Parallelism in Playwright refers to running multiple test spec files or even test cases within a spec file simultaneously, greatly improving test execution speed. This is achieved by running the tests in worker processes, where each worker process is an OS process, running independently, orchestrated by the test runner. All workers have identical environments, and each starts its own browser instance. Parallel execution is particularly beneficial in continuous integration and continuous deployment (CI/CD) pipelines, reducing overall build and testing times. Playwright's architecture inherently supports parallelism, and most modern test runners integrating with Playwright can leverage this feature. The parallel execution feature makes Playwright a highly efficient tool for large-scale web application testing. Enabling Parallelism By default, if you scaffold the project using npm init playwright@latest, parallelism is already enabled. Assuming that Playwright's configuration includes three browsers and there is a single spec file with two test cases, the total number of tests that Playwright needs to execute is 3x2 = 6. ` Playwright will decide on how many workers to use based on several factors: - Hardware support: Depending on the number of CPU cores and other system resources, the operating system will decide how many processes Playwright can spin up. - The workers property in the playwright.config.ts file. - The --workers argument to the playwright test command. For example, npx playwright test --workers 4. The --workers argument overrides the workers property in the configuration. However, in both cases, the number of workers can go up to the number of processes that Playwright can spin up, as decided by the operating system. Once it has determined the number of workers, and if the number of workers is larger than 1, Playwright will then decide how to split the work between workers. This decision also depends on several factors, such as the number of browsers involved and the granularity of the parallelism, which can be controlled in several ways: - In the test spec file, you can specify whether to run the test cases in parallel. To run tests in parallel, you can invoke test.describe.configure({ mode: 'parallel' }); before your test cases. - Alternatively, you can configure it per project by setting the fullyParallel: true property. - And finally, you can set it globally in the config, using the same property: fullyParallel: true. Therefore, if there is more than one worker and the parallel mode is enabled, Playwright will assign test cases to each worker as they become available. This scenario is ideal because it means that each test is stateless, and the resources are used most efficiently. ` Disabling Parallelism What if, however, the tests are not stateless? Imagine one test changes the global configuration of the app via some sort of administration page, and the configuration affects different parts of the app, like enabling or disabling features. Other tests, which may be testing those features, would be impacted and would report incorrect results. In such cases, you might want to disable parallelism. You can disable any parallelism globally by allowing just a single worker at any time. Following the instructions from the previous sections to configure the number of workers, you can either set the workers: 1 option in the configuration file or pass --workers=1 to the command line. ` Let's have a look at our test output in this case: ` Now, compare the time it took with one worker versus the time it took with four workers. It took 8.2 seconds with one worker compared to only 3.9 seconds with multiple workers. That might be an inefficient usage of resources, of course, especially if you have a large test suite and some of the tests are stateless and can be run without impacting other tests. Tweaking Parallelism If you want some tests not to run in parallel, but still want to utilize your workers, you can do that. Again, following the configuration options from the previous sections, you can annotate the entire spec file with test.describe.configure({ mode: 'serial' }); to have the tests run sequentially in that spec file, or use the fullyParallel: false property to run tests sequentially on the project level, or using the same property to run tests sequentially on the global level. This means you can still split the tests between workers, but the tests would be run sequentially within a worker depending on the configuration. For example, let's set the number of workers to 4, but set fullyParallel: false globally. ` The tests need to be run sequentially, but since each browser instance effectively provides an isolated environment, this means tests cannot impact each other between environments, and they are safe to be executed sequentially within an environment. This means setting fullyParallel: false on the global level is not the same as having workers: 1, since the browsers themselves offer an isolated environment for the tests to run sequentially. However, since we only have 3 environments (3 browsers), we cannot fully utilize 4 workers as we wanted, so the number of workers is 3. Conclusion In conclusion, Playwright's workers are the core of its parallelism capabilities, enabling tests to run concurrently across different environments and browsers with efficiency. Through its many configuration properties, Playwright allows you to configure parallelism at multiple levels, offering a granular approach to optimizing your test runs. Beyond just executing tests in parallel on a single machine, Playwright's parallelism can even extend to splitting work across multiple machines through sharding, significantly enhancing the scalability of your testing. We hope this blog post was useful. For those interested in delving deeper into the world of Playwright and its powerful features, we've also recently released a JS Drop titled Awesome Web Testing with Playwright, and we also hosted Debbie O'Brien from Microsoft in a Modern Web episode....

Mar 20, 2024

5 mins

JavaScriptPlaywrightTesting

Quick Guide to Playwright Fixtures: Enhancing Your Tests

Introduction Following our recent blog post on migrating E2E tests from Cypress to Playwright, we've identified opportunities to enhance our test scripts further. In this guide, we'll delve into the basics of Playwright fixtures, demonstrating their utility and flexibility in test environments. Playwright fixtures are reusable components that set up and tear down the environment or conditions necessary for tests. They are crucial for writing clean, maintainable, and scalable tests. Fixtures can handle tasks like opening a browser, initializing a database, or logging into an application—actions you might need before running your tests. As a practical example, we'll revisit one of the tests from our previous post, enhancing it with a new fixture to streamline the testing process and significantly improve maintainability. This post is designed to provide the foundational skills to integrate fixtures into your testing workflows effectively, giving you the confidence to manage and maintain your test scripts more efficiently. Creating Our First Fixture To illustrate the power of fixtures in Playwright, let’s consider a practical example from a test scenario in our project. Below is a snippet of a test case from our newsletter page: ` This test scenario navigates to the newsletter page, fills in an email, submits the form, and checks for a success message. To optimize our test suite, we'll refactor common actions like navigation, form completion, and submission into reusable fixtures. This approach makes our tests cleaner and more maintainable and reduces redundancy across similar test scenarios. Implementing the Fixture Here’s how the fixture looks: ` This fixture encapsulates the actions of navigating to the page, filling out the email field, and submitting the form. By abstracting these actions, we simplify and focus our test cases. Refactoring the Test With the fixture in place, let’s see how it changes our original test file: ` A beforeEach method to reset the state of the NewsletterPage fixture ensures a clean and consistent environment for each test scenario. This practice is crucial for maintaining the integrity and reliability of your tests. By leveraging the NewsletterPage fixture, each test within the "Newsletter page" suite starts with a clean and pre-configured environment. This setup improves test clarity and efficiency and aligns with best practices for scalable test architecture. Conclusion As we've seen, fixtures are powerful tools that help standardize test environments, reduce code redundancy, and ensure that each test operates in a clean state. By abstracting common setup and teardown tasks into fixtures, we can focus our testing efforts on what matters most, verifying the behavior and reliability of the software we're developing. Remember, the key to successful test management is choosing the right tools and using them wisely to create scalable, maintainable, and robust testing frameworks. Playwright fixtures offer a pathway towards achieving these goals, empowering teams to build better software faster and more confidently....

Jul 26, 2024

2 mins

Testing

Building Mobile Applications with Svelte and NativeScript

Have you ever wanted to build a mobile application using a language you already know? In this tutorial, we'll learn how to start building a mobile application using Svelte and NativeScript. What is NativeScript NativeScript is a framework that will allow you to write Native apps using JavaScript or Typescript and, at the same time, it allows you to access platform-specific Native APIs. Setting up your environment The very first step to developing with NativeScript is installing all the required dependencies. If you're lucky, you'll already have everything installed. But if not, we'll see how to get it to work. The first thing (assuming you already have Node installed) is to install NativeScript globally. ` For this tutorial, I'll be developing an iOS application. The best way to check if your environment is prepared is to use the command provided by NativeScript. ` There's an equivalent command for android if that's your target OS. If you are missing anything, you'll get a bunch of messages with the requirements needed. In my case, I had to install XCode, Ruby, Some Gems, and Python libraries. Please refer to the setup guide to check what you need (macOS + iOS, for me). It's important to have your environment ready. Otherwise, we will not be able to run our project. ` Starting a new project Now that our environment is set up, let's start a new project. We are going to base this example app on this sample from the NativeScript samples page. However, we will add more to it, like including HTTP requests, and a List/Detail navigation. ` The command will create a Svelte + NativeScript project, and install the required dependencies. Our folder structure will look like this: We'll be focusing on the /app folder where our JS/TS will be added. ` ` App.svelte will render the default page Home which contains a message and an icon. You'll notice that these are not the HTML tags you're used to, and that's because these are not HTML elements. These are native elements/views. So if you were thinking of reusing your code in a web app, for example, this is not the part that you'll be able to share. If that's what you need, make sure you extract the pieces that can be reused. Building Our Application Let's delete the content from Home.svelte, and let's talk about what we'll be building. The app we will build will display a list of items, and when clicked, will navigate into a detailed view. The date for this example will be fetched from the PokeAPI. Creating a List view Let´s create our Home page a.k.a the list. But first, let's create some types to be used in our list. ` First, we created a type for the rest API response. It will contain a list of Pokémon with a few properties. We also create a type for the model used in our view. ` Our page consists of a set of layouts and a list view. Each list item will display an image and a label. However, our view is missing data. Integrating with PokeAPI Let's create a service that will fetch a list of Pokémon. ` To make a request I'll use the Http API provided by NativeScript. It contains a set of methods that I recommend you to check out before deciding which one will suit better for your use case. I'm making a little transformation to the received data, to build the URL with the sprite of each item. Once our service is in place, we'll fetch data and display it. By default, we will fetch 100 items starting from the first one. I'll make a request once the item is mounted, which means I'll first render the action bar only, and when the response is received, the list will be rendered. ` Our app should look this by now Much better! Adding the Details view For our sample application to be complete, we want to be able to navigate to a more detailed page of a Pokémon when one list item is selected. First, we need to create our destination component: a detailed view of a Pokémon. We will be adding fetching a description for the Pokémon, but there's a lot of information you can get from the API. Let's add this call to the API service, and create our detailed view. ` ` We will be using a set of stackLayout to build our view, display the image, add the name to the action bar, and finally show a loading message while getting the description, and an error if it fails. Notice there are two properties exported. This means that these properties must be passed as inputs from a parent. Bringing all together It's time to connect the list view, and the details view. Let's see the final Home Page: ` We have now included an event listener (on:itemTap), that will then call the navigate method included in svelte-native. Here, we passed the required props item and index to the Details Component. Now we have connected both views. We don't have to think about a back button in our details view because it's automatically there when you navigate, and add a view to the navigation stack. The final result: Success. Publishing your app If you want to publish the application start by running ns prepare ios --release Open the project in XCode and follow the instructions on how to publish an iOS app. Final words Being able to work on a native application using a language and a framework you're comfortable with can be a benefit. But there's a cost to it. Setting up the environment is not as straightforward as it could be, but thankfully, the CLI makes it a lot easier to diagnose what's required. There's a lot more to explore in NativeScript like using plugins, but it's out of scope for this post, where we explore the usage of Svelte with NativeScript. You can check the code from this tutorial in this repo....

Oct 17, 2022

5 mins

Svelte

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

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

A Look at Playwright Parallelism

Quick Guide to Playwright Fixtures: Enhancing Your Tests

Building Mobile Applications with Svelte and NativeScript

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

A Look at Playwright Parallelism

Quick Guide to Playwright Fixtures: Enhancing Your Tests

Building Mobile Applications with Svelte and NativeScript

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh