¿Cómo decides qué cubrir con tests unitarios frente a tests de integración?

Haz tests unitarios de la lógica con ramas y casos límite: reglas de precios, parseo, máquinas de estado. Haz tests de integración de las costuras donde tus suposiciones se encuentran con la realidad: consultas a base de datos, serialización, middleware de autenticación, clientes de terceros. Si un test necesita cinco mocks para funcionar, sobre todo está probando tus mocks y el valor está en un test de integración. Apunta a muchos tests unitarios rápidos más un conjunto más pequeño de tests de integración sobre los caminos críticos.

Lo divido según dónde vive el riesgo. Si el riesgo es lógica, ramas, redondeos, casos límite en una máquina de estados, eso es un test unitario, y debería ser lo bastante rápido como para ejecutar el fichero entero al guardar. Si el riesgo está en una costura, que mi SQL devuelva de verdad lo que creo, que el JSON se serialice como espera el cliente, que el middleware rechace un token caducado, eso es un test de integración con una base de datos real en un contenedor. La heurística que uso es el número de mocks: si necesito cuatro mocks para que un test arranque, ese test afirma mi modelo mental de esas cuatro cosas, y mi modelo mental es exactamente lo que está mal cuando se rompe en producción. También intento ser honesto sobre lo que no pruebo. Un controlador fino que solo pasa datos, o un getter, queda cubierto de forma incidental y probarlo aparte es coste de mantenimiento sin señal. La suite que quiero son muchos tests unitarios rápidos y quizá veinte tests de integración sobre los caminos donde hay dinero o autenticación de por medio.