¿Cómo pruebas los componentes de React y qué decides deliberadamente no probar?

Prueba el comportamiento a través de la misma superficie que tiene un usuario: renderiza el componente, consulta por rol y nombre accesible, interactúa y comprueba lo que aparece. Cubre la lógica que puede romperse de verdad, como el renderizado condicional, los estados de error y de lista vacía, y los hooks personalizados. No pruebes detalles de implementación como el estado interno, el paso de props o que se llamó a un componente hijo; esos tests se rompen con cada refactor y no atrapan nada.

Mi regla es que un test solo debería fallar cuando cambia el comportamiento visible para el usuario. Así que renderizo el componente con Testing Library, consulto por rol y nombre accesible, hago clic y escribo como lo haría una persona, y compruebo lo que hay en pantalla. Eso tiene un efecto secundario agradable: si no puedo consultarlo por rol, el marcado suele tener un problema de accesibilidad. Para la red intercepto a nivel HTTP en lugar de simular mi propia capa de datos, porque simular mi propio módulo significa que estoy probando mi mock. El mayor valor viene de la capa intermedia, una funcionalidad completa renderizada con sus hijos reales y un servidor falso, más que de un test por componente. Lo que no pruebo es el estado interno, que se haya llamado a un helper, archivos de snapshot de un árbol entero, ni los estilos. Todo eso se rompe con refactors inofensivos y pasa mientras algo está genuinamente roto. Luego un número pequeño de tests extremo a extremo cubre los flujos que el negocio no se puede permitir perder, como el registro y el pago, y ya está.