Pruebas de servicios (obsoleto)

Esta es una forma obsoleta de probar servicios. Para servicios nuevos, consulta Servicios de prueba (Well-Known-Component).

Los servicios DEBEN probarse principalmente usando pruebas de API, es decir, un conjunto de pruebas que ejercitan el código del servicio a través de su API levantando el servicio, con sus dependencias externas simuladas (DBs y APIs). Prueba unitaria DEBE incluirse en los casos en que se encuentren secciones de código utilitario con un alto número de casos que ejercitar o código poco eficiente en rendimiento, lo que hace imposible o difícil probarlo con pruebas de API. La razón de esto es que, debido a nuestra arquitectura de microservicios, que reduce las responsabilidades y, por tanto, la cantidad de código que debe probarse, la lógica de los servicios es sencilla, por lo que las pruebas de API son la opción que más tiempo ahorra por valor a la hora de garantizar que los servicios funcionen correctamente.

Stack de pruebas

Los servicios DEBEN probarse usando Jest como el framework principal de pruebas con supertest como el framework para levantar el servidor y probarlo.

Estructura de directorios

Como los servicios PUEDEN tener tanto pruebas de API como pruebas unitarias, habrá más de un lugar donde irán las pruebas:

• Las pruebas unitarias DEBEN ir junto al archivo o módulo que están probando, con el mismo nombre, pero con la extensión spec.ts en lugar de ts.

• Las pruebas de API ejercitarán código a lo largo de todo el servicio, por lo que DEBEN colocarse en un directorio test en la ruta raíz. Los archivos se nombrarán según el recurso del servicio que vayan a probar; es decir, si las pruebas de API van a probar el recurso books, normalmente bajo /books, el nombre del archivo DEBE ser books.spec.ts y DEBE colocarse en el directorio test .

Qué probar

• Los middlewares aplicados a la ruta (auth, etc.), para garantizar que la ruta funcione como se espera.

• La lógica de los controllers, para garantizar que la ruta haga lo que esperamos que haga.

Pruebas de API para servicios

Como se mencionó antes, las pruebas de API se harán usando Jest y supertest.

Para ilustrar cómo haría un desarrollador las pruebas de API, tenemos el siguiente ejemplo:

import express from "express"
import { authMiddleware } from "../auth"
import db from "../db"

const app = express()

app.get('/books', async (req, res) => {
	let books: Books[];
	if(req.query.author) {
		books = await db.getFilteredBooks({ author: req.query.author })
	} else {
		books = await db.getBooks()
	}
  res.json(books)
})

app.post('/books', authMiddleware, async (req, res) => {
	await db.insertBook(req.body)
	res.status(200).end()
})

En el ejemplo encontramos una ruta con diferentes métodos HTTP, GET y POST. Ambos endpoints se refieren al mismo recurso, books, así que debe crearse un archivo, llamado books.spec.ts DEBE crearse bajo el directorio test para albergar las pruebas para ellos.

Todas las rutas y los distintos flujos de ejecución DEBEN probarse a fondo. Estos son los casos que el desarrollador DEBE probar para estos endpoints:

• Solicitar todos los libros funciona, respondiendo con un 200 y la lista de todos los libros.

• Solicitar todos los libros de un autor dado funciona, respondiendo con un 200 y la lista de todos los libros de ese autor.

• Publicar un libro sin autenticación falla, respondiendo con un 401 y un mensaje de error.

• Publicar un libro autenticado funciona, respondiendo con un 200 e insertando el libro.

Sin duda, estos casos obtendrán sus pruebasy la expectativa de esas pruebas DEBE contener al menos el estado de respuesta esperado y lo que se espera en el cuerpo de la respuesta (si lo hubiera).

Así es como deberían escribirse las pruebas de estos endpoints:

import db from '../db'
import app from '../express_app.ts'
// Solo simulamos dependencias externas como DBs
jest.mock('../db')

const mockDb = db as jest.Mocked<typeof db>

const server = supertest(app.getApp())

// Esto también podría escribirse como /books?
describe('cuando se solicita el recurso books', () => {
	let url: string
	let aBook: Book
	let anotherBook: Book
	beforeEach(() => {
		url = '/books'
		aBook = { title: 'aTitle', author: 'anAuthor' }
		anotherBook = { title: 'anotherTitle', author: 'anotherAuthor' }
	})
	
	describe('cuando se consultan los libros sin autor', () => {
		beforeEach(() => {
			mockDb.getBooks.mockResolvedValueOnce([aBook, anotherBook])
		})

		it('debería responder con un 200 y todos los libros', () => {
			return server
	      .get(url)
	      .expect(200)
	      .then((response) => {
					expect(response.body).toEqual([aBook, anotherBook])
	      })
		})
	})
	
	describe('cuando se consultan los libros con un autor', () => {
		beforeEach(() => {
			mockDb.getFilteredBooks.mockResolvedValueOnce([anotherBook])
		})

		it('debería responder con un 200 y todos los libros de un autor', () => {
			return server
	      .get(url)
				.query({ author: 'anotherAuthor' })
	      .expect(200)
	      .then((response) => {
					expect(response.body).toEqual([anotherBook])
	      })
		})
	})
	
	describe('cuando se publica un nuevo libro sin autenticación', () => {
		it('debería responder con un 401 y un error que diga que el usuario no está autenticado', () => {
			return server
	      .post(url)
				.send(book)
	      .expect(401)
	      .then((response) => {
					expect(response.body).toEqual({ error: 'No autenticado' })
	      })
		})
	})
	
	describe('cuando se publica un nuevo libro autenticado', () => {	
		it('debería responder con un 200 e insertar el libro', () => {
			return server
	      .post('/books')
	      .set(createAuthHeaders('post', url))
				.send(aBook)
	      .expect(200)
	      .then(() => {
					// Comprueba que el libro fue insertado
	        expect(db.insertBook).toHaveBeenCalledWith(aBook)
	      })
		})
	})
})