You are setting the component-testing standard for a large frontend. Behavior-only assertions survive refactors but produce vaguer failure messages and slower tests than assertions on internals. How do you weigh that, and where would you allow exceptions?

## Start from the purpose of the suite A test suite exists to make change safe and cheap. Every property you might optimise for — speed, precision, coverage — is instrumental to that. This matters because the tradeoff in the question looks symmetric and is not: a brittle suite does not merely cost time, it degrades the signal until people stop reading it. Once the team's reflex on a red test is "the tests need updating", the suite has negative value: it costs maintenance *and* no longer catches regressions. So the default is not a matter of taste. **User-visible outcomes and outward effects are the standard; assertions on internals are the exception that must be argued for.** ## Taking the costs seriously The two stated costs are genuine, and a principal-level answer addresses them rather than dismissing them. **Vaguer failures.** "Expected to find text *Order placed*" tells you less about *where* the fault is than "expected `status` to be `confirmed`". But this is largely a test-authoring problem, not an inherent property of behavioral testing: - One behavior per test, so the failing test name is itself the diagnosis. - Name tests after the user-facing outcome ("disables submit while the order is in flight"), not after the function under test. - Assert the specific outcome, not a broad "something rendered" check — a precise behavioral assertion is nearly as diagnostic as an internal one. Also worth stating plainly: an internal assertion's precision is precision about the *mechanism*, which is not always where the fault is. It will tell you state changed correctly while the screen showed nothing. **Slower tests.** Rendering a real component tree with real children costs more than poking a function. Two honest responses. First, choose the right unit: logic that has no UI — a price calculator, a validation rule, a date formatter — should be tested directly as a pure function. That is *not* an implementation-detail assertion; it is a different, legitimate unit with its own contract. Second, accept that some slowness is the price of testing the wiring, and control it with test-level selection rather than by weakening assertions. ## Where exceptions are legitimate A standard with no exception path gets ignored. Three exceptions are defensible: 1. **No perceivable handle.** A decorative container, a chart canvas, a scroll region with no text or role. A stable dedicated test attribute is the pragmatic escape hatch: not user-perceivable, but stable across styling churn. 2. **States unreachable through the UI in a unit test.** Some states require a specific external condition. The right fix is usually to make the condition reachable at the boundary — fake the failure at the network seam rather than forcing internal state — but where that is genuinely impractical, a narrow exception beats leaving the case untested. 3. **A different unit entirely.** Extracting logic and testing it directly, as above. What I would *not* grant an exception for: convenience. "It was easier to read the state" is the argument that grows the coupled set. ## Making the standard operational A standard that lives in a wiki is decoration. Three things make it real: - **Review is the enforcement point.** New tests follow the standard; exceptions carry a one-line comment naming what they protect, which makes them reviewable and, later, prunable. - **Remediation rides on ordinary work.** Fix coupled tests when a change breaks them, rather than funding a rewrite programme. The refactor that broke the test pays for the fix. - **Measure the property you care about.** The honest metric is not "percentage of tests using approved queries"; it is *how many tests break on a behavior-preserving refactor*. Run that experiment occasionally. It is the only number that tells you whether the standard is working. ## The boundary with other layers Part of setting the standard is saying what component tests are *not* responsible for, so people stop trying to force those things into unit assertions: appearance belongs to visual checks, real cross-page flows to end-to-end tests, and rendering performance to its own measurement. Being explicit about that removes the main motive for reaching into internals — someone trying to assert a thing this layer was never meant to verify. ## What separates a strong answer A weak answer restates "test behavior, not implementation" with more confidence. A strong one accepts both costs as real, shows they are mostly addressable by test authoring and unit selection rather than by relaxing the rule, defines a narrow and reviewable exception path, and names a falsifiable measure of whether the standard is working. It also acknowledges the organisational reality: a standard that requires a feature freeze to adopt will not be adopted.