Primer test
Tags: javascript, automation, testing, tutorial
Published: 2021-05-09 18:06:05

En el capítulo 1 realizamos la instalación de las librerías que vamos a usar en el proyecto y realizamos la configuración básica para poder usar Jasmine, en este capítulo vamos a organizar nuestro proyecto y realizar nuestro primer test. 

> Ya que deseo utilizar en el tutorial una API real, debemos de crear una cuenta en [TheMovieDB](https://www.themoviedb.org/signup), una vez creada la cuenta, iniciamos sesión, vamos a `Ajustes / Api` y guardamos el valor que se encuentra en `Llave API / API Key (v3 auth)`

**¡Empezemos!**

## Configuración variables de entorno
Lo primero que vamos a realizar es preparar nuestro proyecto para usar variables de entorno por lo tanto en la raíz del proyecto vamos a crear un nuevo archivo `.js` (yo le pondré `environment.js` pero le pueden colocar el nombre que ustedes deseen) y dentro de él colocaremos el siguiente código:

```js
/** environment.js */
require("dotenv").config();

module.exports = {
  API_KEY: process.env.API_KEY || "4p1k3y",
  BASE_URL: process.env.BASE_URL || "http://localhost:3000",
  USER_TMDB: process.env.USER_TMDB || "defaultUser",
  PASSWORD_TMBD: process.env.PASSWORD_TMBD || "defaultPassword",
};
```
Lo que estamos haciendo con estas líneas de código es exportar un [objeto](https://www.tutorialsteacher.com/javascript/javascript-object#:~:text=JavaScript%20object%20is%20a%20standalone,literal%20or%20object%20constructor%20syntax.) cuyos valores de las llaves están tomando los valores de las variables del sistema y en caso de no existir tomar un valor por defecto:

| Nombre | Descripción |
| ------ | ------ |
| API_KEY| Nombre de la propiedad |
| process.env.API_KEY | Nombre de la variable del sistema |
| "4p1k3y" | Valor por defecto en caso de no existir coincidencia  |

En la misma raíz del proyecto un archivo que debe de llamarse `.env` (el archivo debe de llamarse así ya que es el valor por defecto para que `dotenv` lea el archivo, en caso de colocar otro nombre debemos de indicarle a `dotenv` la ruta del archivo que deseamos leer) y copiaremos lo siguiente:

```sh
API_KEY=TuAPIKey
BASE_URL=https://api.themoviedb.org/3/
USER_TMDB=UsuarioCreado
PASSWORD_TMBD=ContraseñaCreada
```

## Creación de rutas
Dentro de `./spec/support` vamos a crear una archivo llamado `routes.js` (En el vamos a especificar las diferentes rutas o endpoints que vamos a estar utilizando) y dentro de el vamos copiar el siguiente código: 

```js
module.exports = {
    authentication: {
        createRequestToken: '/authentication/token/new',
        createSession: '/authentication/session/new'
    }
}
``` 

> Al igual que en `environment.js` acá estamos exportando también un objeto, este contiene las diferentes rutas que vamos a estar utilizando en nuestras pruebas.

## Creación de nuestro primer test
Según la documentación del [API de TheMovieDB](https://developers.themoviedb.org/3) antes de poder iniciar sesión debemos de solicitar un token, este será nuestro primer caso de pruebas: Vamos a validar que en efecto este parámetro esté en la respuesta y validaremos también el código de respuesta.

Dentro del directorio `./spec/`vamos a crear un nuevo directorio llamado tests y dentro el crearemos un nuevo archivo llamado `authentication.spec` y copiaremos el siguiente código:

```js
const axios = require('axios')
const expect = require('chai').expect
const ENV = require('../../environment')
const ROUTES = require('../support/routes')


describe('Testcases for /authentication route', () => {

    it(`Request to ${ROUTES.authentication.createRequestToken} 
    generates new token and responds 200`, async () => {
        const request = await axios({
            method: 'get',
            url: `${ENV.BASE_URL}${ROUTES.authentication.createRequestToken}`,
            params: { api_key: `${ENV.API_KEY}` }
        })
        expect(request.status).eq(200)
        expect(JSON.stringify(request.data)).contain('success')
        expect(JSON.stringify(request.data)).contain('expires_at')
        expect(JSON.stringify(request.data)).contain('request_token')
    })

})
```
- En las primera 4 líneas estamos importando todo lo que necesitamos tanto de librerías como los objetos que creamos para ejecutar nuestros casos de prueba. 
- El bloque `describe` nos permite indicar una descripción de lo que vamos a probar, dentro de el podemos crear otros describe si requieren que sean necesarios y luego declarar los casos de prueba.
- El bloque `it` se usa para definir el caso de prueba
- Al invocar axios debemos de pasarle el método que vamos a utilizar y la url a la que hará la petición, con esto ya es suficiente para realizar una petición, pero debemos de estar pendiente de la especificación del API para saber qué mas debemos de pasarle. Para este caso la documentación no nos pide que usemos HEADERS pero si requiere queryparams, es por eso que le pasamos a axios el parámetro `params` el cual recibe un json. [Documentación Axios](https://github.com/axios/axios)
- Finalmente tenemos las validaciones con expect (pueden usar should) validamos que la respuesta contenga el `status` y que este sea igual a 200, y que dentro de `data` tengamos el request_token que usaremos más adelante para poder crear una sesión.

## Ejecutemos la prueba
Para ejecutar nuestra prueba, desde una terminal ejecutamos `yarn test` o `npm test` y si no hemos cometido algún error de salida tendremos lo siguiente:
![Test output](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r5gjkxhgzlm1b0rqd2kn.png)

Para verificar que nuestro test funciona correctamente vamos a modificar la aserción a que espere que tenga como código de estatus un 201, esto nos debería fallar, `yarn test` o `npm test` nuevamente:
![Fail test ouput](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qayitmkifpa6girzna2i.png)

Podemos evidencia que en efecto nuestra prueba si está haciendo las validaciones correctamente.
Hasta acá llega el segundo capítulo, en la próxima entrada vamos a validar un caso negativo, es decir esperar a que nos retorne error (codigo 4xx y body con mensaje de error). Los casos negativos son con los que podemos verificar si un endpoint está bien definido, si tienen los errores controlados y si en efecto el error es el que se encuentra definido. 

Cualquier cuda o comentario me la pueden hacer saber, responderé a la brevedad :D 

| |
| ------ |
Me gusta escribir sobre testing en general, gracias a esto me doy cuenta de lo que me falta por aprender, también me encanta el café, [por si deseas regalarme uno :)](https://www.buymeacoffee.com/To3Dd6m)