React Testing Library Intro - discussion (2023-01-15)
Testing Library's intro is the link I send when teams get stuck writing tests that mirror component structure instead of user intent. I'm curious how people apply it in apps that lean heavily on route contracts, stored derived state, and render-visible evidence (so tests can assert behavior without peeking into internals).
Do you test route behavior by asserting on UI evidence (data-*, status text), or do you reach into state contracts? How do you keep tests resilient when you have lots of derived keys (counts, visible ids, previews)? What are your rules for getByRole/findBy* vs asserting on async timing explicitly?
Comments (14)
Back to latestAsserting on evidence is the biggest shift.
If the UI renders data-freshness or a status lane, tests can be stable without reading internal state.
A tiny example that matches the "user intent" posture:
tsx
render(<SupportShell><Queue /></SupportShell>);
await userEvent.type(screen.getByRole('searchbox'), 'refund');
expect(screen.getByText(/refund/i)).toBeInTheDocument();
expect(screen.getByTestId('queue')).toHaveAttribute('data-status', 'open');The attribute assertion is the evidence layer; the text assertion is the user layer.
Counterpoint: too much data-* can turn into testing-only API and drift from reality.
We try to keep evidence minimal and meaningful (lane/status/selection), not every variable in the app.
Agree. The evidence layer should explain behavior, not mirror implementation.
If the evidence is only there for tests, it's probably the wrong evidence.
We avoided timing assertions by making async status explicit in the UI.
If the UI renders pending|ok|error, tests can just wait for the status change.
The intro doc also helped us stop snapshotting huge trees.
Snapshots are fine when the output is intentional, but most of our snapshots were just noise.
For derived keys, we treat them as part of the UI contract.
If a derived key affects a badge/count, we assert on the badge/count rather than the key itself.
I still use findBy* when I need to wait for something real (like content appearing after a fetch).
But I avoid sleeping/timeout assertions as much as possible.
One trick: render the current route posture in a visually-hidden element.
Then tests can query it like normal content without relying on classnames.
A misunderstanding I see: people treat getByText as the default for everything.
Roles are better when the UI is accessible, and they make tests more resilient.
Docs tie-in: the repo's emphasis on evidence is basically a testing strategy.
Related: Testing and Debugging and Performance and Rendering (Best Practices).
Counterpoint: sometimes tests *should* reach into a contract (like a vault) if it's explicitly part of the app architecture.
We do it rarely, but for some invariants it was the cleanest assertion.
I think that's fine if it's truly a contract and not an implementation detail.
But I still like having a UI evidence line so the same invariant is visible to humans too.
If your tests are brittle, it's often because the UI doesn't expose enough intent.
The fix might be better evidence, not more mocks.
Playwright vs RTL: we do RTL for component-level route posture and Playwright for full route flows.
But both benefit from the same thing: observable state in the UI.
The intro doc is still the best antidote to "test the implementation" habits.
If you can phrase the assertion like a user expectation, it usually survives refactors.