so far I really like using etaoin. it's fast and uncomplicated, but only got maybe 10 tests so far. I have doubts that E2E-frontend-tests are scalable and I guess they are hard to maintain so I am thinking about alternatives.
Honestly - no Selenium wrapper worked for me, ever. But there are situations where only Selection actually works, so I usually make a macro that retries things over and over until hopefully it works...
In this case, I usually use the Selenium API directly. In all other cases I prefer to use Playwright (it feels more reliable most of the time)
etaion is selenium-free 🙂
Oh, I wasn't aware of that. Interesting deep_thinking
We used Selenium on our legacy apps and it was kind of a pain. For our new apps we used HtmlUnit but recently switched to Playwright. We mostly use it to drive the app but still use explicit assertions on the state of the system, rather than asserting things in the UI. I can't remember whether we tried Etaoin at some point... I'm pretty sure we did, as well as a Selenium wrapper written in Clojure, but I can't remember our experience with either (except that we didn't adopt Etaoin -- and we only used the Selenium wrapper for a while). I'll be interested to hear more about people's experiences with Etaoin...
I remember once I had to use Selenium (it was a react-native project). I made an act-> macro that behaved exactly like thread-first, but if it detected a ElementNotFound or other Selenium error, it would basically retry (up to 10, 20 times, don't remember) instead of crashing.
It was basically the only thing that worked 🤷♂️
As for Playwright, it's what I've been using to test Pulsar (the fork of Atom) and it works really well, even more considering that driving electron apps is still considered experimental.
Heh, we have a couple of macros like that too:rolling_on_the_floor_laughing: