Hacker News new | ask | show | jobs
by jitl 1466 days ago
Given that I don’t know what this is, and that Selenium’s API is well-known to promote flakey tests (it’s flakey by default and needs layers of abstractions to add waits, delays, etc), I’d stay away.
2 comments

Aren't all E2E test frameworks flaky by default? When you're testing the end user experience that goes through multiple layers of services, I think that should be expected.

Would love to learn from your experiences on any better frameworks you might have used, though!

Yeah, Selenium is pretty flakey. I've been pretty happy with https://playwright.dev . Kind of the successor of puppeteer. At least, some of the same devs went from Google to MS. Here's an example where MS has better cross-browswer support than Google.
I second this. I think playwright and cypress are the main ones you should use. We already implemented something for Cypress and looking to do the same thing for Playwright. It'll be pretty similar to this: cypress.preflight.com

Would love to get your feedback so we can add it :)

No not all e2e frameworks are flakey. Cypress allows you to intercept network calls with ease. The same can be done in Playwright as well.
We’re using Hurl [1] at work for integration tests with very good success. We’ve eliminated false positive or flacky tests: it’s a simple tool that runs HTTP requests and you can add asserts on responses.

It’s as if you would test your app with curl, very fast and reliable. On the other hand, contrary to Selenium, there is no Javascript engine so you can only test the “raw” DOM or json response sent by the network (and not a DOM managed and rendered by a Javascript front end framework).

(Disclaimer: I’m one of Hurl maintainer)

[1]: https://hurl.dev

Seems hurl is quite a different thing than browser automation though?

API/request level testing is great when appropriate, but testing what happens in browser won't be possible without using something like selenium, nightwatch or playwright

Yes totally.

On the other hand, you can also easily test use cases where the browser is “helping” you (for instance, you want to test that your backend didn’t accept an invalid email, but your HTML form has HTML5 validation that prevents a user to enter an invalid email). Or you want to test HttpsOnly cookie attributes. But it can’t do UI integration tests.

Cypress completely solved flakey UI tests for me. I used Selenium for years but would never go back now.
Switched from Cypress to Selenium a while ago. It is noticeably quicker to respond to network request waits. Additionally, I prefer Playwright’s locator abstractions to Cypress’ queue/alias system.
I really like playwright's locators as well. It looks pretty cool. We actually have a Cypress POM generator tool which uses AI and let's you test emails etc: https://cypress.preflight.com/