¿Cómo es tu estrategia de pruebas en una aplicación full stack?

Pondérala por riesgo en vez de por el dogma de la pirámide. Pruebas unitarias para lógica pura y casos límite, una capa sólida de pruebas de integración contra una base de datos real en un contenedor, y un número pequeño de pruebas de punta a punta que cubran los flujos que cuestan dinero si se rompen, como registro, pago e inicio de sesión. Simula a los terceros en la frontera de red en vez de sustituir tus propios módulos.

Mi regla guía es que una prueba merece la pena si habría cazado un bug que plausiblemente entregaríamos. La lógica pura, reglas de precios, manejo de fechas, comprobaciones de permisos, lleva pruebas unitarias rápidas con los casos límite desagradables. La capa en la que más invierto es la de integración: petición HTTP real contra la aplicación, Postgres real en un contenedor, migraciones reales, y afirmo sobre la respuesta y las filas resultantes. Eso caza lo que las simulaciones esconden, como una violación de restricción o una consulta que devuelve nada en silencio. A los terceros los simulo en la frontera de red con algo como MSW o una grabación fija, nunca sustituyendo mi propia clase de servicio, porque entonces estaría probando la simulación. La de punta a punta la mantengo deliberadamente pequeña, quizá ocho recorridos que cubren registro, inicio de sesión, pago y el flujo principal, ejecutándose en cada merge. Con la inestabilidad soy implacable; una prueba que falla al azar entrena a la gente a relanzar el pipeline, así que la arreglo o la borro en un día. La cobertura la miro como diagnóstico, nunca como objetivo.