Exercise 2: Why Matching by Label Text Is More Fragile Than an Accessibility Identifier — Possible Solution ==================================================================================================================== A UI test that finds a button by its real, currently-visible label text - for instance, searching for a button literally labeled "Add" - is implicitly depending on that EXACT string staying unchanged forever, even though a button's own visible label is genuinely one of the most likely things to change over a real app's own lifetime: a copy-editing pass might rename it to "New Task," a localization effort might translate the entire app into a different real language (where "Add" would become a completely different string), or a designer might simply prefer different real wording during a later redesign. A real accessibility identifier, by contrast, is a separate, internal string specifically meant to stay stable regardless of what the button's own real visible text says - it's read by tests and by real accessibility tools like VoiceOver, but never actually shown to an ordinary user at all, so there's no real user-facing reason it would ever need to change just because the button's own displayed wording does. CONCRETE SCENARIO: Imagine TaskFlow is later localized into French for a real French App Store release, and the "Add" button's own label becomes "Ajouter" instead. A test written to search for app.buttons["Add"] would immediately, silently fail to find the button at all once the app is running in French - not because anything about the actual add-task feature itself broke, but purely because the test's own search string no longer matches the button's real displayed text. A test written to search for app.buttons["addTaskButton"] instead would continue working correctly in every real language the app ships in, since the accessibility identifier itself never needed to change at all. ANSWER: Matching by label text ties a test to a string that's likely to genuinely change (copy edits, redesigns, and especially localization into other real languages), causing the test to break for reasons entirely unrelated to whether the feature itself still works. A concrete real scenario: localizing the app into French would change "Add" to "Ajouter," silently breaking a label-based test, while an identifier-based test (addTaskButton) would keep working correctly regardless of what language the button's own visible text is currently displayed in. WHY THIS WORKS AS AN ANSWER ------------------------------ This identifies the real, concrete reason label text is unstable (localization, copy changes) and gives one specific, realistic scenario (French localization) where that instability would actually break a real test.