Planeación de pruebas

9/12

Lectura

Planeación de pruebas

Hemos visto las pruebas desde un panorama general, ya vimos lo mínimo que necesitamos conocer y hasta un marco de trabajo basado en pruebas.

Ahora para nuestro proyecto que descargamos, vamos a utilizar estas herramientas y aplicarlas para que se ajusten a nuestras necesidades.

Lo primero que debemos hacer es:

Entender nuestra aplicación

Lo que hace nuestra aplicación es mostrar un pokemon con varias de sus características aleatoriamente y modificar el fondo cada vez que le damos click al boton de “SEARCH”.

Listo…

¿Pero qué hay del código?

Antes que nada, tenemos 2 componentes:

  • App

    • PokeStats

Empezamos explicando el de PokeStats.

Tenemos 3 propiedades que son:

14.png

Como nos damos cuenta, de estas propiedades, dos esperan recibir Number y una String.

A su vez, estas propiedades están bindeadas a una tabla:

13.png

Que a su vez, dentro del bindeo, se dividen entre diez (porque la API nos lo entrega en decímetros y decigramos 😐 )

Y listo, eso es lo único que hace este componente.


Veamos ahora el componente App.

Este componente es nuestro componente principal de la vista.

Del lado de HTML tenemos lo siguiente:

12.png
  • Tenemos un div cubriendo todo, el cual va a actuar como ancla de nuestro componente y al que le vamos a cambiar el fondo.

  • La siguiente etiqueta section nos ayuda a separar la parte del nombre, la imagen y el botón

  • Dentro de este section se encuentra el botón al cual le bindeamos el evento de onClick al metodo setData()

  • En el siguiente section está nuestro componente <poke-stats></poke-stats> junto con una lista de otros elementos del API, la cual llenamos con un v-for

Eso es todo por la parte del HTML, ahora veamos la parte del JS.

En el JS tenemos primero:

11.png
  • Importamos nuestras dependencias, que son nuestro otro componente, un servicio mock (lo explicaremos más adelante) y una librería para hacer peticiones.

  • Nuestra propiedad data() junto con todos los elementos que usamos, todos se inicializan.

  • Una propiedad computada, esta lo que va a hacer es estar escuchando al elemento type y en cada cambio va a cambiar la propiedad backImg, que esta bindeada al div ancla del principio.

Eso es del lado de las propiedades. En los métodos tenemos:

10.png
  • Primero está la inicialización de nuestro componente PokeStats.

  • Luego está el método que se manda a llamar cada vez que apretamos el botón: setData, este recibe la data y escoge un valor al azar entre el 0 y 2.

  • Luego utilizamos el hook de created() para que en ese momento, se haga la petición al servicio y se modifique el data().


Ya entendiendo esta parte, lo que sigue es empezar a preparar todo para probarlo.

¿Preparar todo? ¿Qué no habíamos ya descargado todo lo que necesitábamos?

Así es, solo que al probar el código no se debe romper nada.

Lo que debemos tener más en cuenta son 3 puntos:

  • Cuidar el cómo se comunican los componentes.

  • Checar los cambios entre los estados.

  • Checar los eventos externos a la aplicación.

Dentro de estas cosas podemos detectar que tenemos una funcionalidad que hay que revisar.

Eventos externos

En este caso nuestro data() está cambiando cada vez que presionamos el botón y este cambio se hace por una API externa.

Cuando hacemos pruebas no podemos consumir un servicio directo. Debemos consumir un servicio mock. Esto para no romper el servicio o tener falsos positivos por problemas externos de la aplicación.

Mock, ¿qué es eso?

El mocking es una técnica de desarrollo, para simular el comportamiento dado de una función en específico.

La forma de hacer un servicio mock es la siguiente:

Lo que recibimos de un servicio es una Promesa, entonces empezamos por eso, se debe crear una función que nos regrese una promesa.

NOTA: El archivo donde se encuentre esta función debe estar en la carpeta public.

Nuestro archivo se llama mockCall.js.

9.png

Y contiene lo siguiente:

8.png

Como nos damos cuenta, exportamos una función que regresa una promesa y la promesa resuelve los datos mock, que son un JSON de los datos que vienen en el servicio en bruto.

Una vez hecho este archivo, lo importamos en nuestro componente y lo mandamos a llamar como lo hicimos en el hook created().

Esto nos permite tener el mismo comportamiento, sin afectar el servicio directamente.


Ya tenemos nuestra aplicación lista para empezar a probarla, lo único que hace falta es… probarla.

Cuéntanos en los comentarios si ya conocías sobre el mocking.

Aportes 11

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Muy interesante, es como crear una FAKE API para probar con algunos ejemplos el funcionamiento para que al integrar con la API verdadera estemos seguros que funcionará bien. Yo apenas aprendí a hacer una API en firebase pero así en local con mock me parece interesante y rápido.

Ya conocia el mocking pero esta bueno volver a leerlo! Saluditos!

Realmente esta clase si tiene algunos huecos, y leí dos preguntas muy interesantes que sería bueno que se resolvieran, pero lo más importante, ¿Por qué estamos llamando al mock en el componente? Si el componente es el que debe consumir los datos reales, en teoría el mock es solo para el testing…

No entiendo esta parte, según la técnica TDD se debió haber construido la prueba primero, para llegar a todo lo descrito arriba en los componentes, ¿O estoy equivocado?

conocia algo parecido con laravel para hacer prubeas no recuerdo si se llama igual

Moka Pot Coffee 😉

Porque en el vm llamas al mock en el hook created?? No habria que llamar a un servicio real en el vm y solo a la llamada moqueada en el test??

El mock es para hacer pruebas de la promesa como si fuera la api pero sin ser la api?
Como para trabajar offline o como nos puede servir un mock?

¿Por qué toca ponerlo en el public?

Desconocía por completo la técnica de mocking pero es bastante buena.

Supongo que el mock se lo esta usando para cuando se llame al componente desde el test y también para introducir este concepto, pero como todos dicen, el mock se debería usar en el test y este test crearse primero que el componente.