[ender7]

- UI code spends most of its time interacting with a UI API (Android view framework, whatever iOS uses, DOM/CSS in web). These APIs are enormous and are rarely designed with testing in mind. Mocking or faking the pieces of API that you need to interact with is frequently a daunting or impossible task.

- Followup to the above: because so much of the "work" involved with UI code involves interacting with another API, usage of that API tends to spread itself through the entire codebase like cancer. You can create a careful separation of concerns, but it takes a lot of upfront work, verbose boilerplate code, and constant vigilance -- if you're just handed an existing UI codebase you won't have that luxury.

- UI code is highly stateful and highly mutable. A core skill in UI programming is managing your app's enormous state profile. Single-path, whole-world rendering techniques like React/other shadow DOM techniques really help here.

- UI is highly temporal. It needs to change over time. Testing anything to do with time is an enormous headache. Animations can force you to temporarily separate your underlying state from its representation, which is a testing nightmare. But just in general, writing unit tests that involve time passing is infuriating and fragile (even if you can control time passing via a mocked clock object).

- A lot of core functionality in UI involves different pieces handing off to each other -- one window transitions to another window, etc. To test that properly you need integration tests, but now your integration tests also need to interact with the underlying OS/browser (because you can't separate any of that stuff out). So your integration tests are in general way flakier than you can get on UI-less systems that really only need to worry about faking out a DB of some kind.

[steadicat]

Not to mention that UIs are visual, i.e. defining what is “correct” in terms a computer can understand is very hard. There are dozens of criterias (colors, spacing, borders, shadows, fonts, behavior, etc.), and often what is accetable is fuzzy and sometimes even subjective.

Take spacing: if something moves 200px it's probably broken. But a couple pixels off are usually fine. Unless those 2px are the vertical position of an icon inside a button or two things that need to align. Where do you draw the line? Humans are pretty good at spotting when things look off just by looking at a screen. Computers, not so much (yet).

[ocdtrekkie]

This comment is probably missing the biggest part of the problem: The vast number of end devices that will need to present the UI. Even if you're building for iOS, there's several different devices that you need to account for, each with their own quirks, shapes (notches?). But once you go talking Android or web, you're talking about hundreds of potential niche cases, and all of these can change on a yearly basis.