Mock Roles, not Objects: cómo los mocks pueden ayudarte a diseñar mejor
Cuando pensamos en mocks, lo primero que suele venirnos a la cabeza es “simular dependencias” para poder probar nuestro código sin tocar bases de datos o servicios externos. Pero el famoso artículo “Mock Roles, not Objects” (Freeman, Pryce, Mackinnon y Walnes, OOPSLA 2004) nos propone un enfoque completamente distinto: usar los mocks no solo para probar, sino para diseñar mejor.
Los mocks como herramienta de diseño
Los autores introducen una idea que llaman Need-Driven Development (desarrollo guiado por necesidad). En lugar de escribir primero las clases y luego sus tests, se empieza por la prueba. Si durante el test un objeto necesita colaborar con otro que aún no existe, se crea un mock que representa el rol de ese colaborador.
Más tarde, ese mock se convierte en una implementación real. De esta forma, el diseño surge naturalmente de lo que el sistema necesita hacer, no de una estructura pensada de antemano. Cada prueba va revelando nuevas responsabilidades y dependencias, ayudando a construir un código más modular y con bajo acoplamiento.
El ejemplo del TimedCache
En el artículo, los autores usan un ejemplo muy práctico: un TimedCache (una caché con expiración). Empiezan con una prueba sencilla y, a medida que surgen nuevos requisitos —como cuándo caducan los datos o cómo se recargan—, van introduciendo mocks para cada colaborador: Loader, Clock, ReloadPolicy.
Con cada nueva prueba, el diseño se vuelve más claro. Los mocks sirven como una forma de especificar comportamientos esperados entre objetos, y eso lleva a un sistema más limpio y orientado a roles. No se trata solo de probar que algo “funciona”, sino de descubrir cómo debería comportarse.
Buenas prácticas con mocks
El artículo también deja varios consejos valiosos:
- No mockees clases que no controles, como librerías externas.
- Evita sobreespecificar tus tests; cuanto más rígidos, más frágiles se vuelven.
- Diseña tus mocks alrededor de roles claros, no de detalles internos.
- Usa los mocks para expresar colaboraciones reales, no implementaciones concretas.
En resumen, los mocks deben ayudarte a pensar en qué hace cada objeto y cómo colabora con los demás, no en cómo lo hace por dentro.
jMock y el diseño orientado a roles
Para poner todo esto en práctica, los autores crearon jMock, una librería para Java que permite definir expectativas de comportamiento de forma fluida y legible. jMock verifica automáticamente las interacciones entre objetos, ayudando a mantener el enfoque en el comportamiento y no en el estado.
Qué puedes aplicar mañana en tu código
La próxima vez que escribas una prueba, prueba a hacerlo al estilo “Mock Roles, not Objects”.
En lugar de pensar en “qué clase tengo que instanciar”, piensa en qué papel juega ese objeto dentro del sistema. Crea mocks que representen esos roles y deja que las pruebas te guíen. Verás cómo tu diseño empieza a ser más limpio, más mantenible y mucho más fácil de entender.
Fuente: https://jmock.org/oopsla2004.pdf
