One of the most common questions asked on search engines at the moment by people new to automation. What tool.
"What’s the best tool to start with? “-my company uses both?” “What’s better playwright or cypress”.
It could even be that the company use neither but wants to start using only one of them as approved by security for example.
How can we help those people. Step into the mindset of a Quality Coach or experienced senior, or just give your opinion.
Prototype writing a small number of tests using both and then assess, discuss, and make a decision.
Take a moment to read the best practices section of the documentation for each. You will soon notice they have quite different technical, philosophical, opinions.
Cypress:
Playwright:
One big difference, is the recommended locator strategies.
Cypress encourages the use of data-cy test id’s, so make a unique test only id.
Playwright recommends using accessibility based selectors, and finding elements on the page as a user, or screen reader, would interact with them.
This one different is a great example about how as pools they have different intentions.
But it’s not about “what’s the best tool”, you have to pick the tool that fits your (team-)organization. Playwright might have a higher learning curve for your team.
Good idea, but do keep in mind that your experience can be different when you have a large number of tests.
You then have 1) a lot of test code and a lot of file that you need to keep clean and orderly and 2) a CI pipeline that may take long
I wrote an article about this question focusing on clean code, easy debugging, and a short runtime in the CI pipeline - plus some links to resources that turned out useful for me.
Okay, stepping into “Quality Coach” mode. I completely understand the “what tool?” paralysis that hits newcomers (and even experienced folks!) in automation. The truth is, there is no single “best” tool for everyone. It’s about understanding the context and choosing the right tool for the job.
Here’s how I’d approach guiding someone through this decision, framed around key questions:
API Tests? If you’re primarily focused on testing APIs, then a UI-focused tool like Playwright or Cypress isn’t the right fit. Look at dedicated API testing tools. (Apidog, Postman, RestAssured)
End-to-End UI Tests? Are you aiming to automate full user flows through the UI? This is where Playwright, Cypress, and Selenium WebDriver come into play.
Unit Tests? For testing individual components in isolation, look at testing frameworks like Jest (JavaScript), JUnit (Java), pytest (Python). This area isn’t where Playwright or Cypress shine.
JavaScript Dominant? If your team is primarily JavaScript-focused, Cypress might be a smoother entry point, as it’s JavaScript-based. Playwright is also strong in JS/TS but supports other languages.
Multi-Language Team? Playwright’s support for Python, Java, .NET, and JavaScript makes it a strong choice if you need cross-language support. Selenium also supports multiple languages.
Low-Code/No-Code Desired? If your team has limited coding experience, explore low-code tools or tools with strong record-and-playback features (although these often come with limitations).
Speed of Test Creation? Cypress, with its time-travel debugging and hot reloading, often feels faster for initial test creation. However, Playwright has improved significantly in this area.
Cross-Browser Compatibility? Playwright has excellent, built-in cross-browser support (Chromium, Firefox, WebKit). Cypress officially supports Chromium-based browsers and Firefox but has more limitations with Safari/WebKit.
Stability & Reliability? Both Playwright and Cypress are designed to be more reliable than traditional Selenium. Playwright’s auto-waits often make it more resilient to flaky tests.
Community & Support? Both have active communities and good documentation, but the scale of the Selenium community is still vast.
Offline/Secure By Design:Some companies may have strict security policies that require tools that can run offline or have better control over data transmission. Playwright and Cypress often use cloud-based components to store data, which violates these requirements. Apidog, which is a standalone API testing tool, can function completely offline as its data is stored on your local machine.
Guiding Principles (as a Quality Coach):
Start Small: Don’t try to automate everything at once. Identify a few critical flows and automate those first.
Focus on Value: Automate tests that will provide the most value in terms of reducing manual effort, catching regressions, or improving coverage.
Test Pyramid: Encourage the team to build a test pyramid, with more unit tests, fewer integration tests, and even fewer end-to-end tests.
Maintainability: Write tests that are easy to read, understand, and maintain. Follow coding best practices and use clear naming conventions.
Tool Recommendations (keeping the above in mind):
1.Apidog (API Testing):If you have APIs, start here. Seriously. The return on investment for API testing is often much higher than UI testing, as it catches issues earlier in the development cycle. Focus on testing your API contracts, data validation, and security. Apidog is great for this, because it is a standalone API testing application, it is secure by design, and can function completely offline.
2.Playwright: (End-to-End UI, good balance of power & ease of use) Great choice for cross-browser testing, reliable auto-waits, and strong multi-language support. It’s quickly becoming a go-to tool for many teams.
3.Cypress:(End-to-End UI, JavaScript-centric) Excellent if your team is heavily JavaScript-focused and wants a faster initial learning curve. The debugging experience is fantastic.
Ultimately, the best tool is the one that best fits your team’s skills, project requirements, and long-term goals. Experiment, try different tools, and see what works best for you. Don’t just blindly follow the hype.
It looks like it’s been significantly improved but originally I found most of the Cypress ones to be little more than Brian Mann’s [Cypress founder] opinions–and ignored most of them. We do use data- test id’s occasionally, but also use the same id’s devs are using and it usually works out fine as long as there is good communication. We also made heavy use of Page Objects…which their page doesn’t discourage as much as it used to but even when they more strenuously discouraged it they failed to give any better examples than just login, and POs are helpful well beyond that and even if you’re logging in programmatically.
One thing I find useful to remember is that Cypress at least, despite being a test framework, is primarily designed by developers so sometimes their view of actual testing is rather shallow and limited. Sometimes you have to bend or break the rules to do more useful or “interesting” testing.
(To back up my assertion, this was one of the more memorable examples. I literally googled “Brian Mann heat death of the universe” to find it again: Is it possible to handle errors during `.get`? We need to put a retry process in place. · Issue #395 · cypress-io/cypress · GitHub)
Wait what…“Cypress still spins up a browser in order to just to API testing” why? Lol. Thank you for sharing great tips
I don’t believe there is a single “best tool” in the market. The reason is that a single medicine cannot treat all diseases, and the same applies to tools. Every tool has its pros and cons, so it completely depends on the project and what we want to automate.
If someone is bad at coding, then no matter what they use, Cypress, Selenium, or Playwright, things will be difficult.
I would suggest instead of suggesting that such people are good or bad, we can ask for more context, and then based on that, we can share our thoughts that for automating such tasks, this or that tool can be helpful
People are talking about playwright everywhere but at the end of day it’s just a tool and it is us who will shape how that tool will ease our testing process.