Platforms

The practices are portable. The tooling is not. What "click the button" costs, how you find the button in the first place, and whether you can run a hundred of them at once varies enormously depending on what the application is made of.

#The thing that varies

Every platform has an accessibility tree or an equivalent, and the quality of your automation is very nearly a function of how good that tree is and how much of it the framework exposes.

• The browser has the best one in existence. The DOM is queryable, roles and names are standardised, and three mature drivers compete to expose it.
• iOS and Android have good ones — XCUITest and UIAutomator respectively — reachable in one API through Appium, or natively if you can live inside one platform.
• Flutter renders to a canvas and has no native tree at all, so it supplies its own finder API and its own test harness. Nothing from the browser world applies.
• Avalonia is the interesting case: a cross-platform .NET UI framework with a headless test platform, which means desktop UI tests that run in CI in milliseconds with no display server.
• Desktop generally — WinAppDriver, WinUI, WPF, Electron — is where automation is hardest, because the tree is often an afterthought and there is no equivalent of the browser's tooling.

#Below the UI

API testing belongs here too, and is the level most teams under-invest in relative to its value: the same behaviour, tested an order of magnitude faster and more reliably, with none of the rendering. A great deal of what teams write at the end-to-end level is a slow, flaky restatement of an API assertion.

#Browsers plural

Cross-browser testing has changed shape: the engine count is down to three and the differences that break real applications are mostly in layout, fonts and input handling rather than JavaScript semantics. Running your entire suite on three engines is usually the wrong trade — the article covers what to run where.