A case asserts an element sits at fixed screen coordinates. Why does a raised system text-size setting break it, and what should it assert instead?

## What a scaling setting changes Handheld platforms let a user make text larger, and usually let them scale the whole interface as well. The two settings differ in reach — one grows type, the other grows type and the boxes around it — but both do the same thing to a screen: they **reflow it**. Labels get taller, lines wrap where they did not, rows and cells grow, and content that comfortably fitted now overflows its container or is pushed out of view. Nothing about the product's behaviour has changed. Everything about the arrangement has. That matters to an automated case for two independent reasons. First, this is a setting real people turn on and keep on, so the screens have to work under it. Second, it is the fastest way to discover that a layout was built out of fixed numbers rather than out of its content — a defect that will fire again for a long name, a long price or any other string that outgrows the space someone measured once. ## Why a coordinate is not an identity An assertion anchored to a position is asking the wrong question. Consider what a coordinate check actually claims: - that the element exists — which a lookup by stable identifier proves directly and more cheaply; - that it is in a particular place — which the product is entitled to change whenever content, geometry or scaling changes; - that the place is the one the design intended — which the assertion cannot know, because the number was read off a screen that happened to look right on the day it was written. The result is an assertion that fails loudly for a harmless reflow and stays green through a real defect, because a label drawn cut off is still sitting at exactly the coordinate it always was. ## Assertions that survive a reflow | Fragile assertion | Why scaling breaks it | Stable replacement | |---|---|---| | The element sits at a fixed coordinate | Everything below or beside a grown element moves | The element is found by its stable identifier | | Row three of a list is the target | Taller rows change what is drawn and what fits | The row whose content matches is the target | | A whole-screen image matches a stored one | Every intentional reflow differs from the stored copy | Content and reachability are asserted directly | | A control sits at the bottom of the screen | Taller content pushes it out of the visible area | The control is reachable and enabled | | Text equals a string that happens to fit | The string may now be drawn truncated | Rendered text equals the text supplied | The pattern repeats in every row: assert what scaling cannot move — identity, content, state, reachability — and where geometry genuinely is the behaviour, assert the *property* (**reachable**, **not truncated**, **not overlapping**) instead of the number. ## Truncation is the defect this actually finds Presence is not enough. A label handed a long string and drawn into a box that cannot grow will report the whole string as its content while showing the user two thirds of it. So the check has to compare what was supplied with what is drawn: the rendered text, the line count, or an overflow flag where one is reported. Where nothing reports it, fall back to a bounded structural assertion — the container grew to fit its content, or it scrolls — rather than accepting that a property was set. The same run picks up two neighbouring symptoms that are worth asserting on in their own right: - **Overlap.** Two elements sharing the same pixels means one of them was given a fixed height or a fixed offset instead of being allowed to grow. - **Unreachable controls.** A primary action pushed past the bottom of a screen that does not scroll is a dead end, not a cosmetic complaint. ## Running the check without doubling the suite 1. Decide the boundary: the default setting, and the **largest step the product commits to supporting**. Those two are what the suite has to hold. 2. Pick the screens where the defects live — dense text, tight columns, a fixed header and footer, anything with a row of controls at the edge. 3. Run those screens at the largest step, not the whole suite. Scaling defects cluster; they are not spread evenly across a hundred cases. 4. Assert identity, content, truncation, overlap and reachability. Never an image of the whole screen. 5. Treat a failure as a layout defect by default. A rigid container is a real bug that will come back for longer content. ## What this buys A handful of targeted cases at the top supported step catch clipped labels, overlapping rows, unreachable primary actions and containers that were sized once and never again — and they catch them as named, diagnosable failures rather than as an image diff somebody has to squint at. Just as valuable, writing them forces the rest of the suite off coordinates and onto identity and content, which makes every other case on those screens cheaper to keep alive.