phillipmorrow.com

When I first started my career, every job description you'd read had selenium webdriver in it. Synchronization was important. Some people did it right and some people didn't and when it wasn't done right you ended up with arbitrary waits everywhere in the project, introducing flake and watering down confidence in the suite. Flake, the amount of time it takes to dig out root cause of a test failure, how long it takes to simply glance at a test and deduce what exactly it's testing, these things all become costly if it's hard and time consuming to do. The assignment is to release software quickly and have confidence that tests don't pass when they shouldn't and don't fail when they shouldn't. Understanding the assignment is paramount to success.

Cypress enters the chat... This was a completely different approach. From what I can tell, they render the app under test in an iframe instead of sending http requests to the browsers w3 standardized webdriver api, they use the browsers native api. This made the tests far more stable and dare I say much faster if you used fixtures. With fixtures, you completely remove network traffic from the mix. If you blink you're going to miss everything. The trade offs were many at the time; which I think they've overcome a great deal of them; even some things they said they'd never support.

Cypress Trade offs:

• You could never hit multiple super domains. There is a hacky way to unfocus cypress' iframe, change domains, and then refocus it. I'm pretty sure they don't support it and if your cy commands ever stop working too bad.
• You could never have multiple tabs.
• Cors errors were plentiful. I think they've since solved the problem with a proxy or something.
• It couldn't handle i-frames. You can always disable browser security and create cy commands that handle stuff like this.
• It only supported chrome.

There is also Puppeteer, it also is nearly flake-less if tests were authored correctly. Like cypress and selenium, there are once again trade offs.

Puppeteer Trade offs:

• It only supports chrome. That's about it

Selenium Trade offs:

• No access to network traffic or dev tools. I'm pretty sure you can access chrome dev tools when using a chrome based browser now. I've also used a cool library called selenium wire that used a proxy to intercept network traffic, so it was always possible.
• Flake due to race conditions and network traffic. You could handle some of this with Expected conditions, Fluent waits, and Futures; and I did.

The trade offs made making a decision for a green project frustrating. There was always caveat that wasn't really great to live with.

Playwright enters the chat... It's all the feature richness and compatibility of Selenium. What I like the most is we as playwright users aren't cornered into building a project limited by the boundaries of the opinions of the creators.

Why it's my new favorite:

• You can multithread/multiprocess if you write your tests in a thread/process safe way.
• It doesn't use Http requests like selenium, a proxy and injected javascript/resource have virtual machine or an iframe, it achieves its speed and reliability using a websocket.
• You get the cross browser functionality and even some interoperability with selenium; for example, you can stand up grid and run cross browser tests against it. Cross browser functionality doesn't feel like an afterthought.
• You have freedom to choose whatever selector type you'd like.
• There are bindings for about every language, except for Ruby I've discovered, but don't worry, you can register it as a driver with Capybara.
• You can store browser context and only drag login through the ui one time, if you even have to do that at all. That will likely depend on your situation.
• Like with VCR, you can record network traffic to a HAR file and have truly network traffic free UI tests.

https://playwright.dev/

They're on discord and slack with a massive community. Adoption is important and it speaks volumes if the industry at large is migrating to it.