What end-to-end testing is? How can you get started with it? Why this is one of the most important skills you should have as a developer?
I do believe End-to-end testing for web applications is one of the most important parts. Because it allows you to mimic an end user and see how they would run through your app, and see if there are any bugs.
Let’s explore end-to-end testing in a more comprehensive and detailed manner. Imagine a website like Codename Playground, with buttons and interactive elements. End-to-end tests simulate a user’s journey, clicking buttons and interacting with these elements to ensure everything works together as intended. These tests can be automated and integrated into your deployment pipeline. This means that after every code build, the entire suite of tests runs automatically across multiple browsers like Chrome, Firefox, and Safari. This ensures consistent functionality across different environments by simulating user interactions through a single, configurable script.
It will exert certain things. For example, on your website you have a link alongside your logo which should have the text ‘Login.’
When you click on this link, it should take you to the login page. Then, you can programmatically write it and it’s going to run all of these assertions on all the browsers you configure, until it detects if the path is changed to ‘/login’ or not, again depending on what you wrote in the script.
Now, you might be thinking that this is basically useless. But think about this: when you’re trying to design a user flow for your website, the first-time user might not go to the login page. So, you might design a flow where you want no piece in the user flow is ever broken. You might design a user journey where the first-time user lands on the site, goes to register, fills up their details, and then gets redirected to onboarding. Maybe, in one scenario, they skip the onboarding, and in another scenario, they fill it out. In both cases, then, they are finally redirected to the dashboard.
While clicking the “Login” link should ideally take users to the login page, we can go beyond this basic functionality. By writing a script, you can programmatically test this behavior across all your configured browsers. The script will run checks (assertions) to verify if clicking the link changes the website path to “/login”. Remember, the script’s behavior depends on the logic you define within it.
Now, you might think this is unnecessary. However, consider user flow design. First-time users might not always go straight to login. To ensure a seamless experience, you want to design a user journey that accounts for all possibilities.
This could involve landing on the site, registering with details, and then being redirected to onboarding (which can be skipped or completed). Regardless of the chosen path, the user should ultimately reach the dashboard.
You might design a user journey. This user journey caters to first-time users who land on the site, register, fill in details, and then have the option to skip or complete onboarding before reaching the final destination: the dashboard.
This is just a single user flow. You would have a lot of different components over here in terms of code and pages. But what you want is peace of mind whenever you make any change to any component in this flow. That particular change does not break this particular flow.
So, you can write the test for this particular flow one time as an end-to-end test. It will automatically run every single time without testing this flow over and over again after every single change. This saves a lot of developer bandwidth; it saves a lot of mental headache because you don’t have to worry about anything breaking. Because if anything breaks your test would report it.
So, this is the reason you need end-to-end testing, especially in web applications.
How do we get started with end-to-end testing? Currently, I recommend two options for learning end-to-end testing: the first one is Cypress.
Now, why Cypress? Cypress is a popular choice because of its ease of use. Its syntax is very similar to jQuery, making it concise and clean to learn.
The second framework I want to discuss is Playwright, which is a relatively new option for us. But why choose Playwright over Cypress? Playwright offers greater extensibility and programmability compared to Cypress. For example, Cypress currently lacks native support for testing directly on Safari browsers.
There might be a slight misunderstanding here. While I previously mentioned Safari, it’s more accurate to say that Cypress doesn’t directly support WebKit, the underlying engine used by Safari. Similarly, Playwright doesn’t perform tests on Chrome by default. Both tools primarily use Chromium, the engine powering Chrome, which is also used by Cypress.
Both Cypress and Playwright allow you to write scripts for user journeys. These scripts can be written once and reused for future testing. Whenever you need a new user journey test, you simply add a new script to the existing file. This unified script will automatically run across multiple browsers on your CI server, saving you significant time and effort.
End-to-end testing offers a vital safety net. By failing your build before deployment if any tests fail, it prevents bugs from reaching production, saving you significant time, money, and frustration. Now, choosing between Cypress and Playwright depends on your project’s scope. For smaller to medium-sized projects, Cypress is a great option.
However, for larger projects requiring parallel testing or sharding test cases, Playwright might be a better fit, especially if you don’t want to use the currently required Cypress Dashboard for parallel execution. Playwright offers advantages in terms of speed and customization, but its test script syntax is more verbose. Additionally, Playwright boasts a unique feature: the recorder.
While I haven’t used it extensively, it allows you to manually perform a test once, with the recorder capturing your steps and generating a script you can simply copy and paste for future use.
Conclusion:
This blog stresses the importance of end-to-end testing for web applications, particularly those with high traffic. If you’re not already doing it, consider integrating an end-to-end testing pipeline into your deployment process. Code cademy offers an interactive course on GitHub Actions that can help you achieve this. You can find more information in their launch video or the full-stack learning path.