Improving Cross-Browser Testing, Part 1: Web Application Testing Today | Hacker News Reader

Improving Cross-Browser Testing, Part 1: Web Application Testing Today

hacks.mozilla.org

69 pointsfeross9 comments

I always get nervous when stories about Selenium reach the front page of HN. If at any point in the past Selenium has kicked your dog, please accept my apologies.

Exactly the opposite; Selenium and friends have prevented the kicking of countless dogs I've never even met. Thank you!

Why is that? I've done pretty extensive work using Selenium; it's finicky and sometimes too limited for what I need it to do, but I haven't found serious reason to hate it. Documentation's good, it's exceptions are pretty easy to understand, and it does what it says on the tin without much in the way of surprises or drama. It's usefulness has far outweighed any irritation it might have caused me.

Only thing I'd wish for right now is more robust handling for the frequent StaleElementExceptions that can crop up, but it's not too much pain to work around those yourself IMO.

...come to think of it, why are you apologizing?

Edit: ...seriously, you started Selenium?

On the contrary, I find myself wishing for the transparency and simplicity of Selenium bindings when I work with other (newer) tools... especially tools that hijack control flow and promises. Protractor, Cypress, etc.

Thanks for all of your efforts!

I would also recommend checking out TestCafe.

It injects its testing code into the webpage via an http reverse proxy which means it doesn't require internal access to the browser and thus works for unmodified remote mobiles for example. One can simply get a URL that any browser can go to & start executing the tests. Many of the issues with using WebDriver or DevTools seem to be avoided.

Another part of the architecture I've found really useful is that test scripts execute in a nodejs environment outside the browser sandbox and thus have the ability to run external programs, make their own API calls, and so on.

Do check out https://github.com/microsoft/playwright - Node.js library to automate Chromium, Firefox and WebKit with a single API

Not completely related to the article in question but I have to say that after years of trying many browser testing solutions, Cypress is the first one I have used which actually works the way I want it to and isn't a total PITA to use on a day-to-day basis. I don't have to hack workarounds to common use cases and for some reason they seem have the first implementation of this idea which achieves this. I understand that Selenium is a mature technology but man, it has caused so much pain to be over the years despite the many wrappers around it which have endeavoured to make it ergonomic.

I think there's a minor mistake:

"The program does not continue until the remote end receives the corresponding HTTP response. In the initial browser.go call, for example, the remote end will only send its response once the browser has finished loading the requested page."

I think this should read "until the remote end SENDS the corresponding HTTP response", or "until the LOCAL end receives the corresponding HTTP response."

Good catch, thanks! Should be fixed now.

Reply on news.ycombinator.com