Expositor: Rodrigo Gómez Resumen: El mockeo es una herramienta utilizada principalmente por los desarrolladores; para la creación de software. Su uso para pruebas, fuera de lo que son test unitarios tiende a ser más acotada. Hoy en día, el aumento de la complejidad de las aplicaciones, así como el manejo de un mayor número de pruebas automáticas, hace que utilicemos más esta herramienta; para poder realizar nuestras pruebas. Los objetivos de esta charla son: difundir el uso y utilidad, de esta herramienta. establecer cómo puede servirnos para mejorar nuestras pruebas. compartir un caso real de implementación, que se utilizó para solucionar problemas concretos.

1. Ing. Rodrigo Gómez
mail: rodrigo.e.gomez@gmail.com
twitter: @rodrigo_e_gomez
linkedin: https://uy.linkedin.com/in/rodrigoegomez
El mockeo como
herramienta para pruebas
de software
15 y 16 de mayo, 2017
www.testinguy.org
#testinguy |@testinguy

2. Agenda
• ¿Qué es mockear?
• ¿Cómo sería un mundo ideal para las pruebas?
• ¿Porqué simular el objeto, en lugar de utilizar el objeto real?
• ¿Cuándo utilizamos objetos simulados?
• Casos adicionales para servicios
• Caso real de mockeo “Inteligente” de servicios REST
• Herramientas para mockear
• Preguntas

3. ¿Qué es mockear?
Se trata de simular objetos. Estos objetos
simulados (pseudoobjetos, mock object,
objetos de pega) imitan el comportamiento de
objetos reales de una forma controlada.
Se usan para probar a otros objetos en pruebas
unitarias que esperan mensajes de una clase
en particular para sus métodos, al igual que los
diseñadores de autos usan un crash dummy
cuando simulan un accidente.

4. ¿Cómo sería un mundo ideal para las
pruebas?
“En un proceso de desarrollo perfecto, los mocks de
elementos externos a la aplicación que se desarrolla,
deberían estar disponibles, para cada interfaz que un
desarrollador encuentre, para cualquier aspecto, de
cualquier función que alguna vez encontrará. De modo
que cualquier aspecto, de cualquier función que quisiera
escribir; pudiera ser probado en cualquier momento
(recuerde, ¡estamos imaginando un mundo perfecto!)”
Traducción de fragmento del libro, How Google Tests
Software - James Whittaker / Jason Arbon /Jeff Carollo

5. ¿Porqué simular el objeto, en lugar de
utilizar el objeto real?
En los test unitarios, los objetos simulados se usan para simular el
comportamiento de objetos complejos, cuando es imposible o
impracticable usar al objeto real en la prueba.
De paso resuelve el problema del caso de objetos interdependientes, que
para probar el primero, debe ser usado un objeto no probado aún; lo que
invalida la prueba.
Los objetos simulados son muy simples de construir y devuelven un
resultado determinado, de implementación directa.

6. ¿Cuándo utilizamos objetos simulados?
Los objetos simulados se usan en lugar de objetos reales que tengan algunas
de estas características:
• Devuelven resultados no determinísticos (por ejemplo la hora o la
temperatura)
• Su estado es difícil de crear o reproducir (por ejemplo errores de conexión)
• Es lento (por ejemplo el resultado de un cálculo intensivo o una búsqueda
en una base de datos)
• El objeto todavía no existe o su comportamiento puede cambiar.
• Debería incluir atributos o métodos exclusivamente para el testeo.

7. Casos adicionales para servicios
• Si se necesita escribir un programa que depende de servicios web remotos,
que corren en producción, y no están disponibles en los servidores de
tests.
• Servicios de un tercero, corren detrás de un firewall; y no están disponibles
para testing.
• Para desarrollar offline (Ej: home office), se requiere un set de web
services que funcione offline para probar la implementación.
• Demos offline. Los servicios web pueden no estar accesibles o no estar
corriendo todo el tiempo. Es necesario asegurar, que la demo se pueda
llevar a cabo sin problemas en las situaciones antes mencionadas.

8. Caso real de mockeo “inteligente” de
servicios REST
Situación inicial:
• N aplicaciones, con mockers diferentes por app.
• Los mockeos los manejan los desarrolladores.
• Las N aplicaciones están en un flujo y son interdependientes.
• Las N aplicaciones del flujo, utilizan servicios externos.
• Los servicios externos pueden no tener ambiente de pruebas, pueden
tener costo, pueden tener un ambiente de prueba que no cubre todos los
casos posibles.
• Necesito poder probar variando mis entradas, pero manteniendo una
consistencia en las respuestas y en el flujo.
• Necesito poder ejecutar pruebas automáticas, sin riesgo de generar cargos.

9. Caso real de mockeo “inteligente” de
servicios REST
Solución: Proxy y Mock server unificado, para ambientes de prueba
P
R
O
X
Y
SERVICIO X
MOCKEADO
SERVICIO
X REAL
Header: MOCK-SERVICE-X: OK
Sin header
Response
Request Response
Response
MOCK SERVER

10. Herramientas para mockear
https://github.com/mkotsur/restito

11. Referencias
https://es.wikipedia.org/wiki/Objeto_simulado
https://www.soapui.org/testing-dojo/best-practices/api-mocking.html
https://github.com/mockito/mockito/wiki
http://www.telerik.com/products/mocking.aspx
https://github.com/mkotsur/restito
http://wiremock.org
How Google Tests Software - James Whittaker / Jason Arbon /Jeff Carollo
https://www.infoq.com/news/2008/05/WSMock
http://www.javiergarzas.com/2015/09/dummies-vs-stubs-vs-mocks-vs-spie
s-vs-fakes.html

12. Ing. Rodrigo Gómez
mail: rodrigo.e.gomez@gmail.com
twitter: @rodrigo_e_gomez
linkedin: https://uy.linkedin.com/in/rodrigoegomez
¿PREGUNTAS?
¡MUCHAS GRACIAS!
15 y 16 de mayo, 2017
www.testinguy.org
#testinguy |@testinguy