¿Cómo decides qué probar en una base de código frontend, y con qué?

Prueba el comportamiento al nivel en que lo vive un usuario. Las pruebas de componente que renderizan un componente e interactúan a través de texto visible y roles capturan la mayor cantidad de bugs por unidad de esfuerzo; las pruebas unitarias puras encajan con lógica como el formateo y los reducers; un pequeño conjunto de pruebas de punta a punta cubre los recorridos críticos como el registro y el pago. Evita pruebas que afirmen sobre detalles de implementación, porque se rompen en cada refactor sin capturar regresiones reales.

Mi regla es que una prueba debe fallar cuando el comportamiento se rompe y sobrevivir a un refactor. Así que la mayoría de mis pruebas renderizan un componente y lo manejan como lo haría un usuario, encontrando elementos por rol y etiqueta en vez de por test ids o nombres de clase, lo que además ejercita la accesibilidad del componente. La lógica pura como un formateador de fechas o un reducer lleva pruebas unitarias normales, porque son baratas y rápidas. Luego una pequeña suite de punta a punta en Playwright sobre los recorridos que cuestan dinero si se rompen: registro, inicio de sesión, pago. Las llamadas de red se interceptan en la frontera con un servidor simulado en vez de simulando la función fetch, así la prueba cubre mi código real de peticiones. Lo que evito son las pruebas de snapshot grandes, porque nadie revisa un diff de doscientas líneas y se aceptan a ciegas, y cualquier cosa que afirme sobre estado interno. La otra cosa que exijo es que las pruebas de punta a punta corran contra un entorno con datos sembrados, ya que los datos compartidos e inestables son lo que hace que los equipos empiecen a ignorar los builds en rojo.