Comenzando con pruebas unitarias en Angular

Al iniciar en este mundo de pruebas unitarias muchas veces no sabemos por dónde empezar ya que este es un tema bastante extenso y al inicio nos sentimos abrumados y perdidos. En este artículo les daré unos tips de cómo comenzar a realizar las pruebas unitarias de manera que sea fácil adentrarnos a realizar nuestras primeras pruebas:

Ejecutando nuestras pruebas por primera vez:

Al ejecutar por primera vez el código “ng test” en un proyecto nuevo en Angular veremos que se ejecuta automáticamente la siguiente pantalla, donde se ejecutarán cada una de nuestras pruebas. Normalmente en la configuración de karma está configurado el navegador Chrome.

Como vemos en la pantalla nos muestra que tres pruebas fueron ejecutadas con éxito, la primera es de crear el componente app, la segunda es que se creó el título con el texto ‘app Works!’ y la tercera es que se renderizo un tag de h1. Estas pruebas siempre vienen por defecto en un proyecto nuevo creado en angular cli.

A continuación veremos un ejemplo de una prueba unitaria sencilla:

En este ejemplo vemos que se define una variable “a” y en la prueba unitaria se le da un valor de true a lo cual se espera que sea verdadera, lo cual al ejecutar nuestro comando “ng test” nos mostrará que está correcta nuestra prueba unitaria.

Viendo nuestra cobertura en el proyecto

Al ejecutar nuestro código “ng test --codeCoverage” se creará en la carpeta src otra llamada coverage, de ahí abrimos el index.html que nos mostrará gráficamente cómo tenemos cada archivo spec en cuanto a cobertura de código.

Luego de esto podemos entrar a cada uno de nuestros componentes creados y mirar nuestro código y saber qué nos falta por cubrir. Al entrar observaremos que algunas líneas están sombreadas en rojo y esas nos indicarán qué nos falta por hacerle cobertura.

Haciendo focus sobre nuestras pruebas unitarias:

Al momento de crear nuestros componentes, servicios, directivas, etc con angular cli se crean por cada uno de estos un archivo spec y cuando lanzamos nuestro comando “ng test” o “ng test –code-coverage” se van a ejecutar todas nuestras pruebas unitarias, y en realidad solo queremos ejecutar un archivo de pruebas en particular, para esto ejecutaremos el siguiente código:
Buscaremos en nuestra prueba unitaria algo que diga describe (“App component”), cuando lo localicemos antes del describe pondremos una f, la cual quedaría de la siguiente forma fdescribe(“App component”).

Así se ejecutarán las pruebas unitaria solo en ese archivo spec. También podemos hacer focus sobre alguna prueba unitaria en específico, si lo deseamos es poner antes del “it” de la prueba unitaria una “f” como por ejemplo:

Importando componentes, módulos, servicios a nuestra pruebas unitarias:

Quizás este es uno de los temas que más se dificultan para los que están iniciando una prueba unitaria a un componente que se ha creado, pero no hay problema. Lo primero que debemos hacer es focus sobre nuestro archivo como se mostró anteriormente, lanzamos nuestro servidor usando el “ng test”, al iniciar las pruebas unitarias nos mostrará errores ya que no hemos importado nuestros módulos, componentes o servicios, no se preocupen por esto que karma nos indicará qué nos falta por importar, como por ejemplo:

En la anterior imagen nos indica qué está faltando por importar el httpclient, el cual debemos importar dentro de nuestros imports de nuestra prueba unitaria y así para cada una de las cosas que nos vaya pidiendo nuestra prueba unitaria hasta que se ejecute la prueba que se creó el componente de manera correcta.

Si tienen alguna dificultad con alguna importación pueden buscarla en Google que generalmente ya hay gente que ha tenido el problema y les indicarán qué tienen que importar.

Están los lugares donde debemos importar cada una de nuestros elementos:

• Los declarations: donde importamos componentes, directivas o pipes.
• Imports: donde importamos nuestros módulos.
• Providers: donde importamos nuestros servicios.
• Schemas: en esta generalmente se importa NO_ERRORS_SCHEMA, pero tiene que ser de la librería del angular core, o sino generara errores, este se usa para ignorar errores de plantilla. 

Espías, mocks

En las pruebas unitarias este es uno de los temas con mayor relevancia ya que en nuestros códigos siempre llamamos endpoints y en las pruebas unitarias debemos crear mocks simulando las respuestas de estos.

Para esto existen diversas técnicas para crear los espías en nuestras pruebas unitarias, el primero es crear al inicio de nuestras pruebas una constante con el servicio que vamos a referenciar, el segundo es dentro de cada prueba unitaria.
Esta es una de las formas de crear sobre un servicio cada uno de los métodos.

Const MockUserService = jasmine.createSpyObj('UserService', ['query', 'get', 'post', 'remove', 'put'])

Luego de eso en los providers de nuestras pruebas unitarias tenemos que definirlo de este modo:

providers: { 

provide: {'UserService', useValue: ‘MockUserService’}

 }

Y en nuestro beforeach usar de esta manera el código:

MockUserService.and.returnValue(of(value));

El of se utiliza para subscribers.

El value se define como una variable con la respuesta que nos da el back generalmente son objetos:

value = {

                 data: {name: ‘david’, lastName:’Betancur’}

}

Eso es lo que tratamos de mockear para tener una respuesta exitosa en nuestras pruebas.