Los dobles de prueba resuelven problemas de dependencia al permitir aislar un objeto bajo prueba de sus colaboradores. Existen diferentes tipos como dummies, stubs, fakes, mocks y spies que verifican el estado o comportamiento. Los dobles de prueba guían la definición de tipos desconocidos y permiten testear la interacción entre un objeto bajo prueba y sus colaboradores.

1. TEST DOUBLES

2. Test Doubles
• Dobles de cine de acción
• También conocidos como “Mocks" aunque
estos son un tipo concreto de doble (Mocks
Aren't Stubs)
• Fakes, Stubs, Mocks, Spies, Dummies.

3. Resuelven
• Problemas de dependencia:
• Tests lentos.
• Servicios u objetos no disponibles.
• Falta de separación en la colaboración entre
objetos.

4. Interacción entre SUT
(object under test) y sus
colaboradores

5. Interación

6. Tipos
• Dummies
• Stubs
• Fakes
• Mocks
• Spies

7. Dummy
• Se pasa un objeto pero no se usa. Solo sirve para
cumplir una dependencia (cumplir lista
parámetros).
• Objetos que no afectan al comportamiento que se
quiere testear, no se usan.

8. Dummy
https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html

9. Stub
• Almacena datos o una respuesta predefinida y la
devuelve cuando es invocado.
• Cuando no se quiere invocar a dependencias
reales con efectos colaterales o respuestas reales.

10. Stub
https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html

11. Stub
https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

12. Fake
• Tienen una implementación funcional pero no es
igual que la real. En general, toman un atajo y tienen
una versión simplificada del código de producción.
• P.e. “In memory database” en vez de la base de
datos real. RouteBuilder con clave/valor directo.
• Se difieren del Stub en que implementan lógica
para dar la respuesta.
• Permite verificar estado resultante.

13. Fake
https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html

14. Spy
• Sirve para hacer aserciones de si algo ha ocurrido.
• Permite preguntarle si cierta llamada se ha hecho o
con qué valores se ha llamado.
• Recuerda llamadas y observa silenciosamente. No
hace verificaciones.

15. Spy
https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html

16. Mock
• Validan que el comportamiento deseado haya ocurrido.
• Todos los anteriores verifican el estado. El mock verifica el
comportamiento.
• Un mock dice “Espero que el método a se halla llamado y
sino lanzo un error”.
• Qué métodos, en qué orden, con qué parámetros, número
de veces, etc.
• Fallan si lo que esperan no ocurre o si ocurren otras cosas
adicionales que no se espera.

17. Mock
https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html

18. Mock
https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

19. Construcción
• A mano
• Herramientas:
• Prophecy, mockery, php-mock…
• Sinon, jsmock…
• Mockito…

20. Prophecy
Stub
Stub
Mock
Spy

21. Estado / Comportamiento
• Test de estado: Verifican el estado final tras una
operación en el código de test.
• Test de comportamiento: Verifican como el código
de test interacciones con sus colaboradores
• Diferentes estrategias igualmente válidas. Elegir la
mejor forma según el código a testear.

22. Escuelas
• Classicists (State based, Detroit/Chicago)
• Mockists (Interaction based, London).

23. Mockist
• Mocks para toda las dependencias.
• Favorecen el testing para informar decisiones de
diseño.
• Testear SUT completamente aislado.

24. Classic
• Usar mocks solo para dependencias raras o complejas,
favoreciendo los objetos reales.
• Minimizar acoplamiento entre tests e implementación.
• Testear pequeños clusters de objetos y no en aislamiento.
• Piensan que mockist esta acoplado a la implementación,
mientras que el SUT debería ser una caja negra y solo
pensar en la interfaz externa.
• Piensan que la independencia de los tests es menos
importante que el testear en base al estado.

25. Pueden guiar la
definición de tipos
(colaboradores) desconocidos
Design Upfront (Just in time design)
Need Driven Development
Growing Object Oriented Software Guided by Tests

26. Peligros
• Palabra mock: Entender el concepto que hay
detrás y los diferentes tipos.
• Sobre especificar el funcionamiento del SUT y no
en el resultado.
• Tests frágiles que fallan cuando se cambia la
implementación.
• Integraciones no testadas realmente.

27. Recomendaciones
• No mockear “Value objects”.
• No mockear clases concretas.
• Mockear puertos.
• Mockear clases difíciles de construir.
• Mockear en tests de SUTs que solo interactúan.

28. Resumen
• Resuelven problemas de dependencia.
• Interacción entre SUT y colaboradores.
• Guiar definición de tipos (colaboradores).

29. No puedes testear lo
que no controlas
Injectar dependencias
Delegar en colaboradores