Angular

Why Migrate from Protractor to Cypress?

Published Jan 28, 2022

Updated Feb 13, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

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.

ng add @cypress/schematic

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.

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)

Luis Aviles
Luis is a Senior Software Engineer and Google Developer Expert in Web Technologies and Angular. He is an author of online courses, technical articles, and a public speaker. He has participated in different international technology conferences, giving technical talks, workshops, and training sessions. He’s passionate about the developer community and he loves to help junior developers and professionals to improve their skills. When he’s not coding, Luis is doing photography or Astrophotography.
@luixaviles @luixaviles

"Do What Matters with Who Matters While It Matters" Mark Techson on Leadership

Tracy Lee and Rob Ocel sit down with Mark Thompson, aka "Mark Techson", to explore key themes around personal branding, workplace culture, and leadership. Mark shares his journey of building a strong personal brand, discussing how consistent online presence can shape public perception and create professional opportunities. The conversation provides valuable insights into the art of leading without a formal title, emphasizing the importance of cultural sensitivity and gradual influence in workplace environments. A significant portion of the discussion is devoted to Mark's motto of "Do what matters with who matters while it matters." This practical approach encourages listeners to focus on meaningful work, prioritize important relationships, and make the most of their time. Mark also reflects on the challenges of maintaining resilience in the face of personal adversity, offering a candid look at how to balance personal and professional life effectively. Listeners will find actionable advice on how to take control of their career trajectory, foster a positive work culture, and navigate the complexities of leadership, all while staying true to themselves. Chapters [00:00] Introduction [02:19] Personal Branding and Online Presence [06:36] Navigating Workplace Culture [08:56] The Story Behind 'Well Dressed Wednesdays' [11:12] Developing the "Do What Matters" Framework [13:29] Balancing Public and Private Life [18:10] Overcoming Personal Challenges [20:28] Taking Control of Your Career [22:49] Practical Takeaways for Listeners Follow Mark on Social Media Twitter Linkedin Github Bluesky Sponsored by Wix Studio....

Aug 20, 2024

2 mins

JavaScriptAngularEngineering Leadership

How to Run End-to-End Tests on Vercel Preview Deployments

How to Run End-to-End Tests on Vercel Preview Deployments End-to-end (E2E) tests are an essential part of modern web development. They simulate real user interactions and ensure your application works as expected in a live environment. When you're working with platforms like Vercel, which provide seamless deployment experiences, running E2E tests on preview deployments makes sense to catch any issues before merging your changes into the main branch. However, running E2E tests on preview deployments can be challenging as if the deployment isn’t ready when the tests start running, you’ll get errors when they should have succeeded. The Challenge: Timing Your E2E Tests Imagine you're working on a feature and pushing your changes to a branch. Vercel starts deploying the preview, and once that's done, you want to run your E2E tests automatically. But if the deployment isn't ready when the tests start, they might fail, and you'll be left wondering if the issue is with your code or the deployment process. Github Actions allow us to leverage a combination of actions that work together to ensure that your E2E tests only start once the Vercel deployment is ready. The Solution: Combining GitHub Actions for Seamless Testing To solve this problem, we can use two GitHub Actions in tandem: 1. vercel-preview-url: This action retrieves the preview URL of the Vercel deployment. It runs on push and pull request events, ensuring you get the exact URL of your deployment, which can then be used for further tests or other integrations. 2. github-action-await-vercel: This action waits until the Vercel deployment is marked as "READY". It continuously checks the deployment status, ensuring your tests only run once the deployment is fully prepared. ` Breaking Down the Workflow 1. Fetch the Preview URL: The vercel-preview-url action first retrieves the URL of the Vercel deployment. This URL is unique to the deployment, and we need to know it to run our E2E tests against the correct environment. This step ensures that we have the right URL before proceeding to the next steps. 2. Await Deployment Readiness: The github-action-await-vercel action waits for the deployment to be fully ready. It checks the deployment status at intervals (e.g., every 15 seconds) and only proceeds once the deployment is marked as "READY." This step ensures that your E2E tests don't run prematurely, preventing false failures. 3. Run E2E Tests: Once the deployment is ready, your E2E tests are executed against the live preview. By this point, you can be confident that the environment is fully set up, and any failures will likely be due to actual issues in the code rather than deployment timing. Why This Workflow Matters This workflow is essential for teams that rely on automated testing as part of their CI/CD pipelines. By waiting for the Vercel deployment to be fully ready, you minimize the risk of flaky tests that fail due to timing issues rather than code problems. This approach saves time and effort, as developers can focus on fixing real bugs rather than troubleshooting deployment issues. Moreover, this setup is flexible and can be adapted to various project needs. Whether you're running tests on a simple static site or a complex application, ensuring that your deployment is ready before running tests can dramatically improve the reliability of your CI/CD pipeline. Conclusion In modern web development, ensuring the reliability of your CI/CD pipeline is crucial. By leveraging GitHub Actions like vercel-preview-url and github-action-await-vercel, you can confidently run E2E tests on Vercel preview deployments. However, remember that the Vercel deployment can take some time to deploy, especially for larger projects, so use this approach wisely and ensure you only run it when necessary....

Sep 20, 2024

3 mins

InfrastructureVercelPlaywrightCypress

How to Build a Slideshow App Using Swiper and Angular

Google Slides and Microsoft PowerPoint are the most popular options to build presentations nowadays. However, have you ever considered having a custom tool where you can use your web development knowledge to create beautiful slides? In this post, we will build a slideshow app with the ability to render one slide at a time using Angular, Swiper, and a little bit of CSS. Project Setup Prerequisites You'll need to have installed the following tools in your local environment: - Node.js. Preferably the latest LTS version. - A package manager. You can use either NPM or Yarn. This tutorial will use NPM. Creating the Angular Project Let's start creating a project from scratch using the Angular CLI tool. ` This command will initialize a base project using some configuration options: - --routing. It will create a routing module. - --prefix corp. It defines a prefix to be applied to the selectors for created components(corp in this case). The default value is app. - --style scss. The file extension for the styling files. - --skip-tests. It avoids the generations of the .spec.ts files, which are used for testing. Creating the Slides Component We can create a brand new component to handle the content of the application's slides. We can do that using the command mg generate as follows: ` The output of the previous command will show the auto-generated files. Update the Routing Configuration Remember we used the flag --routing while creating the project? That parameter has created the main routing configuration file for the application: app-routing.module.ts. Let's update it to be able to render the slides component by default. ` Update the App Component template Remove all code except the router-outlet placeholder: ` This will allow you to render the slides component by default once the routing configuration is running. Using Swiper What is Swiper? Swiper is a popular JavaScript library that lets you create transitions that can work on websites, mobile web apps, and mobile native/hybrid apps. It's available for all modern frameworks and it's powered with top-notch features you can find on the official website. Installing Swiper The plugin is available via NPM and you can use the following command to install it in the project. ` Updating the Application Module Next, we'll need to update the application module before starting to use Swiper. ` Using swiper element in the Template It's time to work in the slide component, and make use of the plugin along with the available options. ` For a better understanding, let's describe what's happening in the above template: * The element will create a Swiper instance to be rendered in the component. * slidesPerView will set the number of slides visible at the same time. * navigation will render the navigation buttons to slide to the left and right. * pagination will set the pagination configuration through an object. * keyboard will enable navigation through the keyboard. * virtual will enable the virtual slides feature. This is important in case you have several slides, and you want to limit the amount of them to be rendered in the DOM. * class will set a class to customize the styling. * swiperSlide is an Angular directive that helps to render a slide instance. One important note here is the custom container created under the swiperSlide directive allows us to customize the way we can render every slide. In this case, it's used to set a layout for every slide, and make sure to render it centered, and using the whole height of the viewport. Set the Swiper Configuration As you may note, the template will require additional configurations, and we'll need to create a couple of slides for the component. ` In the above code snippet, the component imports the SwiperCore class along with the required modules. Next, the component needs to install those using a SwiperCore.use([]) call. Later, a BehaviorSubject is created to emit all slides content once the component gets initialized. Using Swiper Styles Since the current application is configured to use SCSS styles, we'll need to import the following styles into the slides.component.scss file: ` Of course, these imports will work with the latest version of Swiper(version 8 at the time of writing this article). However, some users have found some issues while importing Swiper styles (mainly after doing an upgrade from Swiper v6 and v7). For example: ` or an error like this: ` If you got any of those issues, you can give it a try with the following imports instead: ` For the purpose of this demo, we'll attach additional styling to make it work: ` The .my-swiper selector will set the appropriate height for every slide. On other hand, the .swiper-slide-container selector will provide a layout as a slide container. And this is how it will look on your web browser. Live Demo and Source Code Want to play around with the final application? Just open the following link in your browser: https://luixaviles.github.io/slideshow-angular-swiper. Find the complete angular project in this GitHub repository: slideshow-angular-swiper. Do not forget to give it a star ⭐️ and play around with the code. Feel free to reach out on Twitter if you have any questions. Follow me on GitHub to see more about my work....

Mar 23, 2022

4 mins

AngularTypeScriptWeb Development

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

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.

Why Migrate from Protractor to Cypress?

Protractor Will Be Deprecated

Cypress supports Interactive Testing

Cypress Has a Huge Ecosystem

How to Perform the Migration?

Luis Aviles

You might also like

"Do What Matters with Who Matters While It Matters" Mark Techson on Leadership

How to Run End-to-End Tests on Vercel Preview Deployments

How to Build a Slideshow App Using Swiper and Angular

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

"Do What Matters with Who Matters While It Matters" Mark Techson on Leadership

How to Run End-to-End Tests on Vercel Preview Deployments

How to Build a Slideshow App Using Swiper and Angular

Introduction to Zod for Data Validation