The Debate Between Cypress and Playwright
Вставка
- Опубліковано 5 лют 2025
- This session will discuss the two most popular modern web application testing tools in Cypress and Playwright. The two approach the same problems in very different ways - learn how to write end-to-end, API, and component tests using both. You'll come away understanding how to execute them on a continuous integration system. While similar comparisons of Cypress and Playwright focus on finding a winner, this session will go in-depth on the advantages of each tool to help you make an informed decision depending on your use case. Find the slides at slides.com/bah...
@gleb, Cypress does not allow multiple sessions at a time. In some scenarios for example calling features is not feasible to validate because we need two sessions on at a time. Correct me if i am wrong
I pretty much never hit this scenarios and it is always browser vs the server rather than browser sessions. Plus with the current cy.session command that restores the cookies and other state logging back in to continue is not too bad.
I pretty much never hit this scenarios and it is always browser vs the server rather than browser sessions. Plus with the current cy.session command that restores the cookies and other state logging back in to continue is not too bad.
@gleb yes i was taking about the cy.session and to again login back is unacceptable in my highlighted scenarios. By the way someone already raised this query in the Cypress community and hopefully it will be resolved soon. Thanks
Again: two web clients communicating in parallel is a tiny number of tests, most of which can be single web client against a server.
@@gleb yes for few scenarios like live chat .live calling we need to validate lots of cases in terms of end to end flow so for that two session must be require but again it's depends on project requirement and thanks for the quick response.
the biggest plus of the the Playwriht is that it is 4 times faster
Again, different trade offs. Yes, you can be fast if you don't show any types of UI, don't wrap operations so you can understand what is going on, etc. But when you are debugging / writing tests the visual feedback is speeding human development - which is THE most expensive part. See my opinion of comparing speed at slides.com/bahmutov/pyramid-testjsummit
I wanted to ask you a question: how does the webdriver protocol works? Is like the opposite thing of injecting code into the browser?
Yes, it is sending JSON commands through HTTP to the browser where the special code (the driver) receives them and then automates that operation.
@@gleb Great, thank you! For this and also all your videos
Hey Gleb, let me preface my comment by saying that I agree with all the things you said about Cypress like better DX for writing tests, healthy community, great docs. The visual quick feedback from Cypress is indeed imho one of the biggest differentiators when it comes to empowering good engineers when writing code. I've also been looking at most of the blog posts, articles, video and other media comparing the two, and also came to the conclusion that they are in the worst case very disingenuous, or in the best case written by people who don't have much experience with Cypress.
That being said the elefant in the room is the performance of Playwright versus the performance of Cypress, I was a bit surprised that you haven't addressed it in the video, could you comment on this aspect of the comparison?
The elephant in the room is pretty small. You trade off having all the information plus the command log for the speed. But there are different types of speed, see my presentation at slides.com/bahmutov/pyramid-testjsummit and I would optimize for the debugging and maintaining speed rather than raw "find the button, click on it"
@@gleb The elephant in the room is pretty big when we talk about time-to-feedback from our tests. If you want to iterate fast with the product, you need fast feedback from your tests. Cypress can be a slow cow when used for more complex web apps that also do plenty of networking.
Time-to-feedback from tests is not 1:1 replaceable with debugging time. For example you're not debugging your tests every time when you run them. Some teams need to run tests on every merge/commit. Imagine having slow tests in such setup.
Debugging and time-to-feedback are separate topics of testing experience which can be addressed individually by testing framework.
Cypress marketing is strong but I really don't like this "whataboutism" - almost every time when real problems within Cypress project is brought up to the discussion, people instantly try to point out at other things to cover up what's bad. Not nice :)
Gleb, it is still heavily biased: you don't compare the speed, dismiss the main DevX from within VS Code where you see a live browser in Playwright, speculate on syntax and on ability to implement spies. You should stick with your principle of not comparing the tools while being heavily biased! That's what we do at Playwright!
Pavel, no offense, I talked about the speed, and there are different types of speed. DevX within VS Code? Sure, I tried it, and could not get any type of "normal" feedback like I would have when using Cypress. Despite loving VSCode, isn't it weird to tie yourself to just one editor from Microsoft? I speculate on the spies and stubs because the test runs in a different context from the code, isn't it? Sure you can play lots of tricks (like you do for component testing), but it is not the same, no? As far as speculation about syntax - I pretty much described the difference between imperative and reactive functional code styles. I would not take it too close to heart, Pavel, I think you have a great tool, and this comparison was pretty favorable to you. Please, don't tell me what to do, especially in the public comments, looks petty and bad on your part.
I'll continue using cypress 👍
Thanks dude !
Thanks a lot , clear and useful information ,
Most of the time I notice people asking to compare cy and pw for speed ,but in real time it's hardly couple of seconds difference ,
I don't thing any project team change automation framework just to save some seconds ,
I like pw but I prefer cy always ,
1. Easy to write
2. Assertion is easy
3 dedug is easy due to test runner
4,spy and stub network call
Could not have said it better myself
Thanks @glab