This Dot Blog
This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.
Our Journey from Cypress to Playwright for E2E Testing
In this blog post, we share our experience of transitioning our end-to-end (E2E) testing framework from Cypress to Playwright. Faced with a technical incompatibility in our existing setup, we embarked on a journey to find a more robust and flexible solutio...
May 31, 2024
3 mins
What is Cypress Studio?
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....
May 3, 2024
5 mins
Using Cypress with Cucumber in a React Application
Introduction We are going to be learning how to integrate Cypress with Cucumber in a React application. Cypress is the premier end-to-end testing platform to allow you to test user interactions, and end-to-end flows in your application. What is Cucumber? Cucumber creates a layer of abstraction that allows for better communication between business and technical folks, and facilitates the use of Behavior Driven Development (BDD). One of the additional benefits is that it essentially creates documentation, which stays up to date and is easy to share. Cucumber is built to support Behavior Drive Development (BDD). If you are unfamiliar with Behavior Driven Development, you can read Cucumber’s guide on it here: https://cucumber.io/docs/bdd/ Learn more about Cucumber in general here: https://cucumber.io/docs/guides/overview/ What is Gherkin? In the simplest terms, Gherkin is a set of grammar rules that structure plain text for Cucumber to understand and process. Learn more here: https://cucumber.io/docs/gherkin/ Setup Steps - Clone a React app to test against. Here is a link to a photo viewer and search app which we will be using: https://github.com/Yog9/SnapShot You will need to clone the app and get it running before we can move on to next steps. Below is a screenshot of the working app: - Add Cypress as a dev dependency within your application. Install Cypress npm i cypress --save-dev. Once you have completed this step, you should see "cypress": "^10.11.0", or something similar in the devDependencies section of your package.json file. - Open and run Cypress to install it using the binary. You do this by typing the command npx cypress open in your terminal. If it's your first time running this command within your application, Cypress will prompt you to install some example tests and other helper files, and guide you through a basic configuration necessary for Cypress to operate within your application. - Add the cypress-cucumber-preprocessor package to your project. This package was originally maintained by BrainFamily, but was recently taken over by Badeball. You can find it here: https://www.npmjs.com/package/@badeball/cypress-cucumber-preprocessor Use the command npm install --save-dev @badeball/cypress-cucumber-preprocessor You can find the quick start guide here: https://github.com/badeball/cypress-cucumber-preprocessor/blob/a2702f5ce247c96269a0432358ed919b596a4dbb/docs/quick-start.md - Add @bahmutov/cypress-esbuild-preprocessor esbuild https://github.com/bahmutov/cypress-esbuild-preprocessor. Use the command npm i -D @bahmutov/cypress-esbuild-preprocessor esbuild. This should result in "esbuild": "^0.15.13" as well as "@bahmutov/cypress-esbuild-preprocessor": "^2.1.5" becoming part of the devDependencies in your package.json file. Add cypress/webpack-preprocessor to your project. Use the command npm i --save-dev @cypress/webpack-preprocessor to add this package. The devDependencies section of your package.json file should now include, "@cypress/webpack-preprocessor": "^5.15.3" if done correctly. - Configure cypress.config.ts file. Configure specPattern with "**/*.feature" and setupNodeEvents. Here is my file: ` Additionally, you will want to generate a cypress-cucumber-preprocessorrc.json file at the root level of your project in order to handle some additional configuration settings. My file contents are below: ` Organize your files. There are multiple ways to organize your feature files and step definition files. For the purposes of this tutorial, we will place our feature files in a cypress > e2e > features directory, and our step definition files in a cypress > e2e > step_definitions directory. Let's Write Some Tests!! Let's create a simple feature file with some basic scenarios and test steps for this application. Here is a start in app.feature! ` ` Summary As you can see, setting up Cypress with Cucumber is a fairly straight-forward process. There are incredible benefits to using Cucumber with Cypress, particularly related to facilitating communication between non-technical and technical members of a development team, as well as creating ongoing project documentation, and an easy-to-understand guide for what your application or feature is doing....
Feb 10, 2023
5 mins
How to Create Better Test Coverage Using Cypress 10
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. 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 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() | 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: ` 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: ` Use Route Aliases Another recommended practice is to use route aliases to guard Cypress against proceeding until an explicit condition is met. ` 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. ` 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. ` 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. ` 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. ` 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. ` 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....
Dec 19, 2022
6 mins
How to Create a Custom Login Command with Cypress, React, & Auth0
Auth0 is a tool for handling user authentication and account management. Cypress is a tool for writing end to end tests for your application. Getting these two technologies to work together can have a few gotchas, especially if your application is set up to have the end to end tests in a separate folder from your frontend code. Today, we’ll go over the steps you’ll need to implement so you can have a custom Cypress command to log in a user, and also let your front end code continue to work safely! --- Setup For this setup, we're making the choice to keep our end to end tests in one folder, and our front end code in a sibling folder. You don't have to do it this way. It's just the choice we've made for this project. So our folder setup has two root level folders, "cypress" and "app": ` --- React Adjustments Auth0 provides a default login form for you to use. We’ll focus on the fact that the forms use web workers to store the user’s access tokens in memory. This helps them keep that access token more secure from attackers. This is important to note for Cypress. But because Cypress does not have a way to interact with that web worker. So we need to be able to detect when our application is running the site through Cypress so we can adjust how we get the access token. We’ll need to update the way our Auth0 form saves that token based on if our app is running normally, or if it’s running through Cypress. To do this, we can add a check to the cacheLocation prop in our Auth0Provider field that wraps around our root app component. app/index.ts ` > Important note if you’re using TypeScript: > If your project is using TypeScript, there will be two more small changes you might need to make. > First, your editor may be yelling at you that it doesn’t know what Cypress means, or that it doesn’t exist on the window interface. So you can make a type file to solve this. src/types/globals.d.ts ` > Then, in the root level tsconfig file, we need to add an option to the compilerOptions section so it knows to look for this file we just made and use it. Then your editor should be happy! :) app/tsconfig.ts ` And that’s all your front end code should need to work! It’ll continue to work as expected when running your app locally or in production. But now when you run your Cypress tests, it’ll store that access token in local storage instead, so we can make use of that within our tests. --- Cypress Adjustments Now we can make our custom login command! Having a custom command for something like logging in a user that might need to be repeated before each step is super helpful. It makes it faster for your tests to get started, and doesn’t need to rely on the exact state of your UI so any UI changes you might make won’t affect this command. There’s a few different things we’ll need to handle here: - Writing the custom command itself - Making an e2e file where we’ll set up this command to run before each test - Updating the Cypress config file to know about the environment variables we’ll need - If you’re using TypeScript, you’ll also need to make a separate “namespace” file and an index file to pull all the pieces together. We’ll start with the meat of the project: making that custom command! I’ll share the whole command first. Then we’ll walk through the different sections individually to cover what’s going on with each part. The Custom Command Cypress automatically sets up a support folder for you, so you’ll likely already find a commands file in there. This will go in that file. If you don’t have it, you can create it! cypress/support/commands.ts ` The first piece to note is line 2. Cypress.Commands.add('loginWithAuth0', (username, password) => {... This is what actually tells Cypress “hey, this is a command you can use”. The name can be anything you want. I’m using “loginWithAuth0”, but you could call it “login” or “kitty” or whatever makes the most sense for your project. Just make sure you know what it means! :) Lines 3-6 are setting our the environment variables that the Auth0 call will use. Then, on line 8, we use Cypress to make the actual request to Auth0 that allows us to log in. For this use case, we’re choosing to login with a username and password, so we tell the call that we’re using the “password” type and send all the necessary environment variables for the call to work. (You can find info on what these values should be from the Auth0 docs.) Then, on lines 20 and 21, we’re starting to deal with the response we get back. If the call was successful, this should contain the information on the test user we just signed in and the access token we need for them. So we extract those values from the body of the response so we can use them. On line 22, we again use Cypress to get the browser’s window, and let us store the user access token. We'll use localStorage for this as seen on line 23. Important note here! Pay extra special attention to the way the string is set up that we’re storing in localStorage on line 24! Auth0 needs the access token to be stored in this specific manner. This is the only way it will find our token! So make sure yours is set up the same way. The rest of the code here is taking the information we got from the Auth0 call and adding it to our new localStorage value. You’ll see that on line 35 we’re parsing the user information so we have access to that, and then setting an expiration on line 40 so the token won’t last forever. And that’s it - our command is set up! Now on to the rest of the things we need to set up so we can actually use it. :) Supporting Files If you have commands that should be run before every test call, you can create an e2e file in your support folder. These are your global imports and functions that will apply to all of your Cypress test files. Here we’ll import our custom commands file and actually call our new command in a beforeEach hook, passing in the test username and password we want to use. cypress/support/e2e.ts ` > TypeScript Note: > To get the typings to work properly for your custom commands, you’ll need to do two things. > First, you’ll want to make a new file called namespace in your “support” folder. Then, you’ll want to declare the Cypress namespace in there, and set up a line for your new custom command so Cypress knows the type for it. (If you originally edited the default Cypress commands file, you’ll also want to go to the bottom of that file and remove the namespace section from it - this is replacing that.) ` > Then in your support folder, create an “index.ts” file and add your commands and namespace imports to it. ` > That should clear up any TypeScript related warnings in your files! The final piece is updating our Cypress configuration file. We need to add all the environment variables we need in here so Cypress is aware of them and we don’t have them hard coded in our files. cypress.config.ts ` Wrap Up With that in place, you should be good to go! Whenever you run your Cypress tests now, you should see that a user is automatically logged in for you so you start on the first page of your app. We hope this helps! If you run into any issues or have questions on anything, please feel free to reach out to us. Leave a comment on this post or ask in our Discord. We’ll be happy to help!...
Nov 18, 2022
6 mins
Cypress 10 - The Latest Release Details - Component Testing, Configuration Options
Cypress 10 was recently released with some long awaited features and bug fixes! In this article, I will talk about some of the exciting features in the latest releases of 10.3.0, 10.2.0 and 10.1.0. Some of these features include component testing, changes to the Cypress configuration file, a new design for Cypress Onboarding UI Design, enabling Cypress natively for Apple silicon and Linux ARM64 and AArch64 systems, and adding live test data into the Cypress Dashboard! Critical features of Cypress 10 Cypress 10 release was announced on June 2022. This was a feature-packed release with many community-request features like component testing, TypeScript improvements, improved onboarding experience, improved error messages, Cypress configuration files, and more. To learn more, check out ChangeLog for a detailed list. Component Testing Let’s start with component testing. Component testing is directly integrated into the main Cypress application. Testing applications to achieve full coverage could be done using many approaches. Major web frameworks focus on breaking applications into components to create a complex functional component. Component testing allows you to test components independently in isolation, and focuses on the functionality of the particular component providing more focused coverage. End-to-end testing focuses on testing the entire application to ensure the application runs as expected while unit testing breaks down the application into smaller individual units of functions, methods, or modules tested in isolation. Unit testing provides little interaction between components and the application, which tends to make debugging difficult. The new Cypress 10 component testing provides component interaction between other components and the entire application. This is rendered in a real browser providing access to dev tools, and making debugging a lot easier during tests. To learn more about component testing, check out GitHub Issue #21111. To learn more about Cypress 10 and other included features, you can check out the announcement blog. Cypress Config File To provide a flexible and extensible configuration option for testing, Cypress 10 now supports multiple configuration file types, including TypeScript, CommonJS, or ESM Module configuration, and drop the cypress.json configuration file. The Cypress configuration file can be cypress.config.js, cypress.config.ts, cypress.config.cjs, or cypress.config.mjs file. 20643. A configuration file is required in a project. Running cypress open will walk you through to set up your Cypress project with specific testing options for your project. 20643. Cypress Onboarding UI Design Project set up for Cypress 10 now takes you through a beautiful UI, built with Vue. Running cypress open renders the on-boarding UI with specific instructions for your test configuration, and allows you to choose between end-to-end testing or component testing. Cypress 10.2.0 A minor version release of Cypress 10.2.0 was announced on Jun 21, 2022. This release focuses on machine compatibility for Apple and Linux distros. Cypress is now available natively on Apple silicon. This means no extra system configuration with emulators, and approximately 2.5x faster testing environment on Apple devices including M1 and M2. 19908 20686 Cypress is now natively available on ARM64 and AArch64 systems running Linux 22252. To learn more about the 10.2.0 release read Cypress 10.2.0: Run tests up to 2x faster on Apple silicon (M1) Cypress 10.3.0 A minor version release of Cypress 10.3.0 was announced on Jun 28, 2022. This version focuses on improving the cloud testing developer experience workflow. Cypress added actionable test data in the Cypress Dashboard from the test runs. Cypress Dashboard is a service by Cypress to provide access to recorded test results when running Cypress tests from a CI provider, giving insight to the tests which helps with tracking and debugging. With Cypress 10.3.0, test result data are directly retrieved and cached whenever possible to provide real-time metrics for test coverage. New columns include #21250: Latest runs to monitor, run, and fix tests locally within CI workflows. Average duration to help quickly identify and take action to improve the performance. To learn more check out Cypress 10.3.0: Speed up testing workflows with improved visibility into your test results Conclusion What do you think of these new features and the latest release? Make sure to read the ChangeLogs for a complete list of features in the releases including bug fixes. To start using the latest Cypress, run npm install cypress@latest --save-dev from your browser....
Jul 25, 2022
4 mins
Utilizing Cypress Testing in a Multi-App Monorepo
For web developers, Cypress is a pretty well-understood testing library that everyone has at least come across or heard of. Getting it set up for an app is pretty straightforward, and you can be off and writing tests in a matter of minutes. But what if you have a monorepo with multiple apps? Do you set up a per-app test suite and manage multiple sets of code in multiple places? Or have you already set that up and noticed that there's a lot of redundancy with potentially shared code that you'd like to refactor into one place? I was recently tasked with setting up such a Cypress testing structure in our Showcase section for our starter.dev project. The idea of the Showcases is that we utilized each of our framework packages to create a GitHub clone as an advanced example of an implementation of each. So they all have the same exact UI to the user, but underneath the hood, they all utilize different sets of technologies for the JavaScript framework, GraphQL/Rest, or CSS libraries. I instantly figured that there had to be a way to write one set of tests that could be utilized against each app, and all I had to do was unify the data-testid attributes across all of the apps. But how do you set it up to automate the process, and against so many different apps? Would it even be possible to start, test, and stop each app through a script? Thankfully, the answer is yes -- and this blog will document and explain a structure that I used when solving that problem. Prerequisites If you've already been developing in a monorepo and have everything set up for that, you likely already have all requirements necessary to install Cypress. However, if you're not and you're setting everything up from scratch, the Cypress docs list a few system requirements: * macOS 10.9 and above (64-bit only) * Linux Ubuntu 12.04 and above, Fedora 21 and Debian 8 (64-bit only) * Windows 7 and above (64-bit only) If you're on a Linux distrobution, pay special attention to the dependencies you'll be needing as well. If you're using npm, you'll need: * Node.js 12 or 14 and above It's possible to download Cypress directly, but I don't recommend that approach for the purposes of this guide. Project Structure For this example, I will be showing the structure I used in the starter.dev GitHub Showcases repository. But hopefully it demonstrates that it's flexible enough to be used on any monorepo structure with any number of apps. The folder structure will look something like this when we're done (showing just two apps and the relevant folders/files for succinctness): ` Installation In the root of your project, you'll want to make your directory where your Cypress tests will exist (replace tests-e2e with whatever you'd like your folder to be called): ` Then, once inside this folder, install Cypress via npm: ` Or via yarn: ` Next, we'll install start-server-and-test, which will be needed later on to automate starting our apps and running our test suite against them. Let's also install TypeScript: ` Or via yarn: ` In the newly created package.json in this folder, let's add a basic script to open Cypress: ` Configuration Now that we have everything installed, we can start configuring Cypress. Let's open Cypress via the newly created script in our last step, npm run cypress:open or yarn run cypress:open. Once Cypress opens, select the E2E Testing configuration and click continue at the bottom of the list to create all the default files (make sure to read what each one does if this is your first time using Cypress!). You should see in your folder structure that Cypress created a number of files and folders automatically, but let's create a few additional folders: ` Inside cypress/configs let's create a file called app1.config.js, or app1.json if you're using a Cypress version older than 10 (replace app1 with the name of one of the apps you want to test against): ` Just regular JSON format for versions prior to Cypress 10: ` A couple notes, baseUrl is the URL your app will deploy on when started up, startCommand is the commmand your app uses to start (for me, it was different for a few different apps, but if yours all use the same command you may not need this), and integrationFolder is where all the test .spec files will be. This can be customized if you've already decided that you'd like your tests to be written separately and/or only one of them will need unique tests, etc. But we can leave it alone for now. Additionally, Cypress has quite a few configuration options. But, the one I'd like to point out specifically is the env option. Just like a .env file, you can utilize this to pass in specific parameters or options into your Cypress tests. Specifically, the different apps I was getting this test suite working against handled auth differently in a few cases, so I needed to visit a specific URL to fire off a redirect/auth chain to mock its state. It looks like this (will be the same in any version of Cypress): ` This may not be something you specifically need yourself, but you can pass in whatever you need for your specific apps, and it will only inject into the Cypress state for that app's Cypress config file. So, maybe you could use this to get the name of what app you're testing, etc. Next, let's add a basic test file inside cypress/e2e or cypress/integration if under Cypress 10. Call it whatever you'd like, but I'll name it first-test.cy.ts (or first-test.spec.ts if you're using a Cypress version older than 10): ` Lastly, let's set up a few run scripts to automate running against all our apps. Update the scripts section of your package.json as such: ` For Cypress versions prior to 10: ` Tying it all together If your entire project structure is set up properly and the file names and configurations all match names properly as described at the start of this blog, the scripts should work as is. The usage would looks like this: ` ` The first command, test, runs through all of the test specs that your config file you set up points to in the integrationFolder option in the command line. This option is good to quickly verify passing tests in the background and/or on your CI/CD pipeline. It first fetches the config file from cypress/config/, grabs the baseUrl from that config file, utilizes start-server-and-test to start your target app, and once it's running, it will run your test suite and tear everything down. This is a powerful and flexible option to then chain together running all your Cypress test suites for all your apps back to back from the same place. The next option, test:watch is the option you'll want to use when developing tests. All it does is open Cypress against the target app's config file you've set up. Then in another process, you will still manually need to start your app locally. The benefit of this is once you change code in either the app or your Cypress test spec files, both will update automatically while everything is still open. Conclusion The solution laid out here isn't one for every single monorepo. However, I believe it can eliminate redundancy for certain types of monorepo structures where each app inside is similar enough, or even more rarely, each app _is_ the same but the target deployments or underlying technology is different. Instead of a per-app Cypress installation and test suite in each app package, this may be exactly the solution to abstract or even refactor them to one single place. There's even flexibility built into this structure to allow a unique set of tests against only one or some of the apps you will need to have integration tests for. Of course, this is only the first step. But hopefully it eliminates potentially the most problematic one. If you'd like to read further on writing Cypress tests themselves, we also have a great guide on writing tests themselves with Cypress that you can check out....
Jul 7, 2022
6 mins
Why Migrate from Protractor to Cypress?
Great memories come to my mind when I read about Protractor. I remember those days when I was working actively using the AngularJS framework to build Single-Page Applications, and Protractor was the most viable option for writing E2E(End-to-End) tests. In fact, Protractor was created in 2013 when AngularJS was the most popular web framework, and it allowed developers to run tests through a web application in a real browser, along with interaction commands to mimic the user behavior. As expected, the ecosystem around JavaScript technologies has been changing continuously, with new tools emerging that afford developers more modern options for writing tests. Is this the right time to think of other alternatives? In this post, I'll give you some reasons to migrate to Cypress since it's one of the best alternatives for E2E testing. Protractor Will Be Deprecated The Angular team has announced the deprecation of Protractor in May 2021. Some of the reasons behind these deprecation plans are: - State of Protractor. Protractor is dependent on selenium-webdriver, and is not able to upgrade to the new version without introducing a huge breaking change, and forcing users to do a migration for all their tests. - Web Testing Landscape. There are different testing solutions today, and they offer better stability and improved support for features like cross-browser testing. The current deprecation timeline looks like this: - Angular version 12 (May 2021) - Announcement of deprecation - Angular CLI will not include Protractor for new projects - Show warning when @angular-devkit/build-angular:protractor is used - Only PRs that address security issues and fixes for browser releases that break Protractor tests will be merged - Angular version 15 (end of 2022) - End of development on Protractor There is a closed RFC with the future of Angular E2E & Plans for Protractor on GitHub with more details about this. Cypress supports Interactive Testing First, we'll need to understand that as part of the _Cypress tooling, there's a Test Runner and a Dashboard Service available for your test suite. - The Test Runner is an open source project available to run your test suite in an interactive environment in real-time. While it's in progress, a command log will display the results of your tests. - The Dashboard Service can record your test run, and enables access to your results. The above screenshot shows an example of the test runner in real-time, where you will find an intuitive way to navigate through the different steps in your tests. Cypress Has a Huge Ecosystem That’s true if you consider the number of resources you can find about Cypress nowadays. It's evolving every day, and it's adopted by developers and QA engineers using modern JavaScript frameworks. As part of the Angular ecosystem, we can mention one of the biggest players: Nx, which is widely used with Angular projects. For this tool, Cypress is used by default while generating new applications. > Cypress will be used by default when generating new applications. If you want to continue using Protractor, set the e2eTestRunner to protractor in the schematics section of the angular.json file. In case you're using Nx, please refer to the Updating your E2E testing configuration guide for more information. How to Perform the Migration? The Cypress team is actively working on the Cypress Angular Schematic, which allows adding Cypress for E2E testing in your Angular projects. You'll need to run the following command and pay attention to the output. ` Here's what happens in the background: * Cypress tooling gets installed in your project. * Some npm scripts are added in your package.json file to run your tests. * "cypress:open": "cypress open". This script will open your browser and render the content of your app. * "cypress:run": "cypress run". This script will run your tests headlessly (the browser will not be opened). * Cypress configuration files and directories are created. * Initial tests and scripts are generated so that you can run Cypress for the first time. * It has the ability to update the default ng e2e command to use Cypress instead of Protractor. If those steps don't work for you, you may need to do the upgrade manually and the good news is that Cypress documentation has you covered already: Manual Installation. Are you ready to learn more about Cypress? Do not miss this topic on our blog site. Feel free to reach out on Twitter if you have any questions. Follow me on GitHub to see more about my work....
Jan 28, 2022
4 mins
Cypress testing your IndexedDb contents with @this-dot/cypress-indexeddb
There are several use-cases where an application uses indexedDb to store data locally. Accessing indexedDb during tests is not that straightforward, that's why we created this cypress helper library. Introducing @this-dot/cypress-indexeddb...
Jan 6, 2022
4 mins
Svelte Component Testing with Cypress + Vite
Cypress is a well-known e2e and integration testing framework, but it can be used to render and test components in isolation. In this blog post, we will set up our environment to test Svelte components while using Vite....
Dec 2, 2021
4 mins