A la hora de probar el funcionamiento de una app conectada a un servicio oData, generalmente necesitamos disponer de una serie de datos concretos para testear todos los casos de uso de la app:
- Crear un usuario.
- Requisito: que no exista otro usuario con el mismo nombre.
- Los usuarios dados de baja también se tienen en cuenta
- Requisito: que no exista otro usuario con el mismo nombre.
- Dar de baja un usuario.
- Dar de alta un usuario dado de baja.
- Modificar un usuario.
- Requisitos: que no esté dado de baja.
- …
Generar estos datos puede ser algo tan simple como insertarlos en nuestra base de datos de desarrollo (crear un usuario e intentar crear otro con el mismo nombre) o tan complejo como necesitar una serie de pasos involucrando varios procesos que nos generen exactamente el caso que necesitamos (crear un usuario, darlo de baja e intentar editarlo).
Esto puede ser especialmente pesado en casos que requieran de varios pasos, o incluso que no sepamos/podamos generar los datos por nosotros mismos y necesitemos que un compañero nos eche una mano. ¿Quién no ha necesitado en algún momento que le preparen un pedido de más de tantos miles en una sociedad de un país concreto, en un periodo cerrado y que cumpla un montón de requisitos más para probar una situación que está generando un bug? Y lo peor es cuando ese caso tan pesado de preparar se «gasta» porque para probar el bug hay que realizar una operación que lo modifica y no se puede deshacer.
Para evitar esto, disponemos de los mocks. Realizar un mock (o mockear) viene a ser generar una capa intermedia entre el origen de los datos (el servicio oData) y las operaciones a realizar (la app) de manera transparente para estas; así podemos realizar estas operaciones atacando esa capa sin que afecte a los datos reales y preparar los datos que necesitamos sin necesitar generarlos en el origen.
¿Ha quedado claro? Veamos como hacerlo.
En primer lugar, necesitamos crear un archivo mockServer.html
que utilizaremos como punto de inicio de la app mockeada, en vez del index.html
. Tan fácil como copiar el index
, pegarlo en la ruta webapp/test
y modificar el data-sap-ui-oninit
para cambiar el valor "module:sap/ui/core/ComponentSupport"
por "module:my/tools/test/initMockServer"
. La ruta raíz (en mi caso "my/tools"
) está formada por el dominio y nombre de al app; en tu caso será diferente. ¿Cómo saber cuál es la tuya? Por ejemplo, en cualquiera de los view.xml
tendrás el controllerName
indicando la ruta absoluta del archivo controller
que le corresponde (en mi caso "my.tools.controller.Main"
, lo que hay antes de controller
es la ruta raíz) .
El archivo webapp/test/mockServer.html
quedaría algo así:
Y el archivo initMockServer.js
:
En la primera línea hemos definido un mockServer
en la ruta webapp/localService/mockServer
, ahora vamos a crear ahí el archivo mockServer.js
:
En el atributo rootUri
hay que indicar la ruta complete del archivo oData
que queremos mockear.
Indicamos qué valores contendrá la entidad del oData
que queremos. Para eso vamos a crear un archivo .json
con el mismo nombre que dicha entidad en la ruta webapp/localService/mockdata
, que es la que le acabamos de indicar en el segundo parámetro de mockServer.simulate()
. Por ejemplo Users.json
.
Y ya solo nos queda crear una configuración con la que ejecutar nuestra app mockeada.
Vamos al menú run/Run Configurations:

Seleccionamos Run as Web Application

Indicamos el archivo que inicializará nuestra app mockeada, marcamos el checkbox de «Run with mock data», guardamos y ya dispondremos de una configuración para ejecutar nuestra app mockeada.

Ahora tenemos dos usuarios Juan y Jose con los que probar nuestra app sin modificar los existentes en la base de datos.
Espero que os haya gustado, os ayude en vuestro día a día y os sirva para dejar de marear a los pobres funcionales pidiendo que os preparen mil casos de prueba.
0 comentarios