People around me have used https://playwright.dev/ successfully and you can program it in multiple languages. That’s for web sites though.

For real applications (like C++ or C#) it’s still a mess but it works fine, nothing really broke for the past 10/15 years.

The synchronization problem (flakiness and all the waits) is tricky to get right. Browsers are concurrent systems, and programming around one is specialized enough that many devs don't do it well, e.g. IMO if you're adding ad-hoc waits or nesting timeouts, you've already lost.

RobotFramework is pretty nice.

The core challenges still exist, particularly with web automation. But RobotFramework at least has much better helper methods, syntax and quality of life tools than a few years back.

I still don't typically see teams maintaining anything deeper than a few smoke tests, for most projects.

Edit: I also see a decent number of folks using PlayWright pretty happily.

Source: I consult with various dev teams on this kind of thing.

I think the situation has improved, but still far from perfect. Last time I used robocop and Python to build some tests. But that's not something I use often, so there may be better options available.

Laravel has a system called dusk where you can specify what buttons to click and what to expect. It will save screenshots of each step. It was pretty reliable in my experience.

I have also tried using Selenium myself to scrape a site but it was very flakey and unreliable.

Yeah I've given up on integration tests.

We have a just do "smoke testing" — essentially a documented list of steps that a human follows after every major deployment. And we have various monitoring tools that do a reasonably good job detecting and reporting problems (for example, calculating how much money to charge a customer is calculated twice by separate systems, and if they disagree... an alert is triggered and a human will investigate. And if sales are lower than expected, that will be investigated too).

Having said that, you can drastically reduce the bug surface area and reduce how often you need to do smoke tests by moving as much as possible out of the user interface layer into a functional layer that closely matches the user interface. For example if a credit card is going to be charged, the user interface is just "invoice number, amount, card detail fields, submit, cancel". And all the submit button does is read every field (including invoice number/amount) and send it to an API endpoint.

From there all of the possible code paths are covered by unit tests. And unit tests work really well if your code follows industry best practices (avoid side effects, have a good dependency injection system, etc).

I generally don't bother with smoke testing if nothing that remotely affects the UX has changed... and I keep the UX as a separate project so I can be confident the UX hasn't changed. That code might go a year without a single code commit even on a project with a full time team of developers. Users also appreciate it when you don't force them to learn how their app works every few months.