Challenge 2: CSS Class vs. User-Visible Text — Possible Solution
====================================================================

wrapper.find('.is-active').length === 1 is fragile because it depends
entirely on an IMPLEMENTATION DETAIL that has nothing to do with what
a real user actually experiences: the specific CSS class name
"is-active" chosen by whoever wrote the component's styling. If a
future developer renames that class to "selected", refactors the
styling approach to use a CSS-in-JS solution with generated class
names, or restructures the component's markup entirely — all while the
feature keeps working PERFECTLY for real users — this test breaks
anyway, for a reason that has nothing to do with an actual bug.

A test that instead asserts the user can see text confirming an item
is selected (for example, checking that the text "Selected" or a
checkmark icon with an accessible label is visible) is testing the
ACTUAL, USER-OBSERVABLE OUTCOME the feature is supposed to produce.
That assertion remains valid regardless of how the component's
internal styling or markup structure changes, as long as the feature
itself keeps behaving correctly from a real user's point of view.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is a direct, concrete illustration of this chapter's warn-box:
testing implementation details (a CSS class, an internal prop, a state
variable) creates tests that fail on harmless refactors and pass
through actual behavioral bugs that don't happen to touch the specific
detail being checked. Testing user-observable behavior instead means
the test only fails when something a real user would actually notice
has broken — exactly the property a genuinely useful test needs, and
exactly what Chapter 3's Testing Library philosophy is built around.