Servicios con dependencias

Clase 8 de 25 • Curso de Angular: Unit Testing para Servicios

Cesar Elías Armendariz Ruano

student•

Angular tiene un concepto importante conocido como inyección de dependencias. Es decir que podemos inyectar servicios, componentes, directivas o pipes a otros componentes, directivas, pipes, etc.

En estos casos cuando un servicio depende de otro o un componente depende de otro se debe realizar pruebas de la siguiente manera.

primero crearemos un servicio extra

ng g s services/master

y vamos a ingrersar el siguiente código

master.service.ts

import { Injectable } from '@angular/core';

import  { ValueService } from './value.service';

@Injectable({
  providedIn: 'root'
})

export class MasterService {
  constructor(
    private valueService: ValueService
  ) { }

  getValue() {
    return this.valueService.getValue();
  }
}

Como se puede observar masterService tiene una inyección de dependencia de valueService.

Para poder realizar las pruebas en valueService ingresar el siguiente código en el master.service.spec.ts

master.service.spec.ts

import { MasterService } from './master.service';
import { ValueService } from './value.service';

describe('MasterService', () => {
  it('should be return "my value" from the real service', () => {
    const valueService = new ValueService();
    const masterService = new MasterService(valueService);
    expect(masterService.getValue()).toBe('my value');
  });
});

como masterService recibe como parametro en su contructor un servicio de valueService, para poder realizar las pruebas desde masterService es necesario crear ambas instancias y enviar en masterService a valueService como parametro.

Importante

En las pruebas unitarias, todo lo que venga como dependencias lo vamos a ejecutar de forma fake o mock. Quiere decir que solo se va a verificar la funcionalidad exacta de esa prueba por ejemplo

Si getValue en valueService es probada, su test sera ver si devuelve el valor asignado en la variable privada value.

Mientras que si la función getValue es provada desde masterService, su test verificara si se esta llamando correctamente la función getValue desde ValueService.

Por lo que para probar se debera hacer mocks de todo lo que venga como dependencias. Por que lo único que se debe probar es su ejecución, no si funciona como tal

Mocks o servicios tipo fake

para observar lo que se hace en un mock vamos a crear un archivo dentro de services llamado 'value-fake.service.ts' y añadimos las funcionalidades de value.service

value-fake.service.ts

export class FakeValueService {

  constructor() { }

  getValue() {
    return 'fake value';
  }

  setValue (value: string) { }

getPromiseValue() {
    return Promise.resolve('fake promise value');
  }

}

Ahora lo importamos a nuestro master value y configuramos mediante un as unknow as ValueService para verificar que se ejecuta la prueba sin necesidad de observar si las funciones de value service se producen correctamente.

master.service.spec.ts

import { FakeValueService } from './value-fake.service';

it('should be return "other value" from the fake service', () => {
    const fakeValueService = new FakeValueService();
    const masterService = new MasterService(fakeValueService as unknown as ValueService);
    expect(masterService.getValue()).toBe('fake value');
  });

Esta es la forma menos eficiente de hacer pruebas sobretodo de mantenimiento.

Otra forma de hacerlo es con un objeto, por que los objetos en JS funcionan como clases o casi como clases por lo que puedo hacer que se pase directamente con un objeto en master.service.spec.ts.

Por lo que, cuando master service lo ejecute probara un fake que se esta enviando en forma de objeto

master.service.spec.ts

it('should be return "other value" from the fake object', () => {
    const fake = {getValue: () => 'fake from obj'};
    const masterService = new MasterService(fake as ValueService);
    expect(masterService.getValue()).toBe('fake from obj');
  });

Esto es especialemente util al momento de probar funcionalidades que por ejemplo se conectan a una API como google maps. Si al momento de hacer pruebas llamamos al API KEY de google maps se puede consumir tantas veces el servicio de manera consecutiva que

consumiria mucho saldo por uso de la API KEY
podría verse como un ataque de DNS y cancelar tus servicios.

Para evitar todo esto se enviar un fake y con eso evitamos el consumo inutil de servicios.

Tomás Gálvez

student•

Existen métodos para no ejecutar un servicio de dependencia real sino uno fake, con el propósito de emular las respuestas, permitiéndonos centrarnos en el servicio a testear y no en las dependencias.

Fake Services: Hacer mocks/clones de los servicios dependencia (método poco mantenible)

Esto es un cascarón del servicio, retornando métodos con valores predefinidos, fakes.

it('sould return "other value" from the fake service', () => {
    const fakeValueService = new FakeValueService();
    const masterService = new MasterService(fakeValueService as unknown as ValueService);
    expect(masterService.getValue()).toBe('fake value');
  });

Usar objetos como clases:

Nos permite hacer una función dentro de un objeto en la misma prueba, emulando el método a testear.

it('sould return "fake from obj" from the fake object', () => {
    const fake = { getValue:()=>'fake from obj' }
    const masterService = new MasterService(fake as ValueService);
    expect(masterService.getValue()).toBe('fake from obj');
  });

Estas formas son manuales, hay maneras automatizadas de hacerlo con Spies

Carlos Alejandro Hernández Mejía

student•

Servicios

💡 Lo servicios en Angular funcionan gracias al patrón de Inyección de dependencias, el cual nos permite inyectar nuestro servicios en diferentes lugares cómo componentes, directivas, etc.
Cómo desarrolladores, también nos encontraremos con el escenario dónde tengamos que probar componentes que depende de un servicio e incluso, servicios depende de otros servicios. Es ahí donde la inyección de dependencias puede ser una herramienta o un problema más (sino la podemos usar).
Algo a tener en cuenta, es que nuestra pruebas unitarias deben encargarse solamente de evaluar la responsabilidad que le corresponde a la función o clase que estamos evaluando.
💡 Es decir, a un conjunto de pruebas unitarias no le debe importar sí una dependencia funciona bien o no, ya que dicha dependencia debería tener su conjunto de pruebas unitarias que se encarguen de verificar su correcto funcionamiento.
Una forma de hacer pruebas unitarias de un servicio que depende de otros servicios es utilizar la técnica de inyección de dependencias. Esto implica proporcionar a la clase o función que se está probando una instancia de cada uno de los servicios que depende, en lugar de crearlos directamente en el código.
De esta manera, puedes proporcionar versiones "simuladas" o "mock" de los servicios dependientes durante las pruebas, lo que te permite controlar el comportamiento de los servicios dependientes y asegurar que tu código se está ejecutando correctamente.
Puedes crear mock services (u objects) para cada uno de los servicios que depende tu servicio y configurarlos para que devuelvan valores predefinidos cuando se llamen. Esto te permite probar tu servicio de manera aislada sin depender de los servicios reales, lo cual es realmente útil cuando quieres probar servicios que se conecta a una API (por citar un ejemplo), debido a que de esta manera, te evitas el consumo de recursos externos.
⚠️ Es fundamental asegurarte de que tus pruebas sean lo suficientemente exhaustivas para cubrir todos los casos de uso posibles y garantizar la calidad de tu código.

Carlos Gomez

student•

Una buena forma de hacer los mocks es implementar los databuilders de cada servicio o clase

Edward Alexis Uceda Jara

student•

¿es necesario colocar como as unknow al faveValueService para recién forzarlo a ser de tipo ValueService?, please alguien ayúdeme

Danny Pacheco

student•

En este ejemplo si es necesario porque nuestro FakeValueService si bien es cierto es una copia, le falta un método del observable y un atributo, es decir, que le falta cosas para que sean iguales, por lo que al colocar unknown y luego ValueService evitas errores de compilación, y se fuerza al objeto a que sea tratado como instancia de Value service. Si hubiera sido el caso donde copiabas todo tal cual no era necesario hacerlo como en clase debido a que como ya sabemos que FakeValueService es una copia exacta de ValueService, tenemos acceso a la definición de ese servicio, es decir que conocemos que su estructura es igual, podiamos definir el tipado explícitamente de esta forma

const fakeValueService: ValueService = new FakeValueService();

Aldo Gabriel Martinez

student•

Increíble, recien lo entendi a ultimo la importancia de la clase.

Cristian Leandro Aristizabal Giraldo

student•

Hubiera sido bueno que getValue() de master, hubiera tenido un nombre diferente a getValue de Value.service.

Así, no sería un trabalenguas

Edward Alexis Uceda Jara

student•

cierto

Servicios con dependencias

Introducción

Unit testing para servicios en Angular

Jest vs. Jasmine: entornos de testing para Angular

Fundamentos de unit testing en Angular

Tu primera prueba en Angular

Explorando matchers

Reporte de coverage

Mocha Report

Testing en servicios

Pruebas unitarias para servicios

Servicios con dependencias

Spies

Angular TestBed

TestBed + Spies

Proyecto

Setup y maquetación del proyecto

Product Service Http

Testing en consultas HTTP

HttpClientTestingModule

Generando Mocks

Pruebas para GET

Pruebas maliciosas para GET

Pruebas para POST

Pruebas para PUT y DELETE

Bonus

Pruebas a errores

Pruebas con interceptores

Pruebas al login

Pruebas a la API del navegador

GitHub Actions

Próximos pasos

Toma el Curso de Angular: Unit Testing para Componentes