Hound works very well for this. I am currently deploying hound against a django bff that runs in front of a django backend and it was incredibly effective at demonstrating that the elixir replacement backend that I wrote is an effective substitute that doesn’t die after long term burn in testing.

I can’t compare it to anything else (it’s been ages since I used capybara) but I wrote a repeating test and having it be a supervised process in elixir meant I didn’t have to nail down all corner cases (also my tests called out other services like ssh to confirm side effects), if it crashed the tests would restart from a safe state

I tried wallaby, but there were simply a few things that couldn’t trigger as reliably as hound does, so I stuck with hound, even though it’s imperative syntax is less to my liking. I got used to it though.

We tried both out and ended up going with Wallaby. The experimental chrome driver has been working out great for us!

There is Wallaby also… both Hound and Wallaby work well for automated E2E browser testing.

Yes, 100%. At work I replaced a python backend with elixir (I’m coming for the python frontend next) and tested that it worked by running a user story continuously using hound for one week in our staging/lab environment (against the python frontend). Discovered several errors, and since deploying to prod there have been zero backend errors.

As a protip, if you do this, BEAM supervised restarts are key and I found that I needed to System.cmd(“killall”, [“chromedriver”]) on each restart, because I found that chromedriver could become helplessly lost in the face of our high-latency python frontend that doesn’t handle conflicting state very well, but that’s another story altogether.