Writing Browser Automation That Doesn't Break Every Week
The most common complaint about browser automation isn't that it's hard to write — it's that it keeps breaking. Almost every case we've seen traces back to a handful of avoidable habits, not to some inherent fragility in the approach.
Selectors are the first thing to fix
Automation built on brittle selectors — deeply nested CSS paths, auto-generated class names, XPath tied to exact DOM structure — breaks the moment a front-end team ships an unrelated styling change. Selecting by stable attributes instead (explicit data-testid-style hooks, accessible roles, visible text) survives far more of the changes that would otherwise break a script, because those attributes tend to be the ones a front-end team treats as a contract rather than an implementation detail.
Waits should be conditional, not fixed delays
A fixed sleep(3) between actions is the single most common source of both flakiness and wasted time — too short and the page hasn't finished loading, too long and the script is slower than it needs to be. Waiting explicitly for a specific condition (an element becoming visible, a network request completing, a loading spinner disappearing) is more code up front but removes most of the timing-related failures that make automation look unreliable.
Treat error recovery as part of the spec, not an afterthought
Real automation runs against a live system that occasionally does something unexpected — a slow page load, an unexpected modal, a session timeout. Deciding upfront what the script should do when a step fails (retry once, screenshot and log the failure, or abandon and alert a human) turns a silent overnight failure into a clear, diagnosable one the next morning.
The maintenance cost is the actual cost
The initial script is rarely where automation projects go over budget — the ongoing maintenance as the target site or application changes is. Writing with stable selectors, explicit waits, and defined failure behavior from the start doesn't eliminate that maintenance cost, but it reduces it enough that automation stays a net time-saver instead of turning into a second job.