Verifying components.
WHAT TO TEST
Behaviour as a user experiences it.
WHAT NOT TO TEST
Implementation detail: internal state, which functions were called.
WHY
Tests coupled to implementation break on every refactor, and prevent improvement.
WHAT THAT MEANS PRACTICALLY
Find elements as a user would identify them, by role and accessible name.
WHAT THAT ALSO ACHIEVES
It surfaces accessibility problems, since an element with no accessible name is hard to find in a test and hard to use with a screen reader.
WHAT TO TEST FOR EACH COMPONENT
That it renders correctly for given props That interaction produces the expected result That every state renders
WHAT TO SUBSTITUTE
Network requests, so tests do not depend on a server.
WHAT TO TEST END TO END
The most important paths, few in number.
WHY FEW
They are slow and fragile.
WHAT MAKES THEM FRAGILE
Depending on structure or on timing.
WHAT TO DO ABOUT TIMING
Wait for conditions, never for durations.
WHAT TO RUN AUTOMATICALLY
All of it, on every change.
