Testando Serviços (Obsoleto)

Esta é uma abordagem obsoleta para testar serviços. Para novos serviços, por favor consulte Testing Services (Well-Known-Component).

Serviços DEVERIAM ser principalmente testados usando testes de API, ou seja, um conjunto de testes que exercitam o código do serviço através da sua API iniciando o serviço, com suas dependências externas sendo mockadas (DBs e APIs). Teste unitário DEVE ser incluído nos casos em que se encontra trechos utilitários de código com um grande número de casos a serem exercitados ou código não performático, tornando impossível ou difícil testar com testes de API. A justificativa por trás disso é que, devido à nossa arquitetura de micro-serviços, que reduz as responsabilidades e, portanto, a quantidade de código a ser testada, a lógica dos serviços é simples, fazendo dos testes de API a opção com mais valor por tempo ao garantir que os serviços funcionem corretamente.

Stack de testes

Serviços DEVEM ser testados usando Jest como o framework principal de testes com supertest como o framework para configurar o servidor e testá-lo.

Estrutura de diretórios

Como os serviços PODEM ter tanto testes de API quanto testes unitários, haverá mais de um lugar onde os testes irão:

• Testes unitários DEVEM ficar ao lado do arquivo ou módulo que estão testando, com o mesmo nome, mas com a extensão spec.ts em vez de ts.

• Testes de API irão exercitar o código ao longo do serviço, então ELES DEVEM ser colocados em um diretório de teste , no caminho raiz. Os arquivos serão nomeados como o recurso do serviço que eles irão testar, ou seja, se os testes de API irão testar o recurso books, normalmente sob /books, o nome do arquivo DEVE ser books.spec.ts e DEVE ser colocado no diretório de teste diretório.

O que testar

• Middlewares aplicados à rota (auth, etc), para garantir que a rota funcione como esperado.

• A lógica dos controllers, para garantir que a rota faça o que esperamos que ela faça.

Testando serviços via API

Como mencionado antes, testes de API serão feitos usando Jest e supertest.

Para ilustrar como um desenvolvedor fará testes de API, temos o seguinte exemplo:

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()
})

Encontramos no exemplo uma rota com diferentes métodos HTTP, GET e POST. Ambos os endpoints referem-se ao mesmo recurso, books, então um arquivo, chamado books.spec.ts DEVE ser criado sob o diretório de teste diretório para abrigar os testes para eles.

Todas as rotas e os diferentes fluxos de execução DEVEM ser testados minuciosamente. Estes são os casos que o desenvolvedor DEVE testar para esses endpoints:

• Solicitar todos os livros funciona, respondendo com um 200 e a lista de todos os livros.

• Solicitar todos os livros de um determinado autor funciona, respondendo com um 200 e a lista de todos os livros desse autor.

• Publicar um livro sem autenticação falha, respondendo com um 401 e uma mensagem de erro.

• Publicar um livro autenticado funciona, respondendo com um 200 e inserindo o livro.

Esses casos definitivamente terão seus its e a expectativa desses its DEVE conter pelo menos o status de resposta esperado e o que é esperado no corpo da resposta (se houver).

É assim que esses testes de endpoint devem ser escritos:

import db from '../db'
import app from '../express_app.ts'
// Nós apenas mockamos dependências externas como DBs
jest.mock('../db')

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

const server = supertest(app.getApp())

// Isto também pode ser escrito como /books?
describe('quando solicitando o 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('quando consultando os books sem um autor', () => {
		beforeEach(() => {
			mockDb.getBooks.mockResolvedValueOnce([aBook, anotherBook])
		})

		it('deve responder com um 200 e todos os livros', () => {
			return server
	      .get(url)
	      .expect(200)
	      .then((response) => {
					expect(response.body).toEqual([aBook, anotherBook])
	      })
		})
	})
	
	describe('quando consultando os books com um autor', () => {
		beforeEach(() => {
			mockDb.getFilteredBooks.mockResolvedValueOnce([anotherBook])
		})

		it('deve responder com um 200 e todos os livros de um autor', () => {
			return server
	      .get(url)
				.query({ author: 'anotherAuthor' })
	      .expect(200)
	      .then((response) => {
					expect(response.body).toEqual([anotherBook])
	      })
		})
	})
	
	describe('quando publicando um novo livro sem autenticação', () => {
		it('deve responder com um 401 e um erro dizendo que o usuário não está autenticado', () => {
			return server
	      .post(url)
				.send(book)
	      .expect(401)
	      .then((response) => {
					expect(response.body).toEqual({ error: 'Unauthenticated' })
	      })
		})
	})
	
	describe('quando publicando um novo livro autenticado', () => {	
		it('deve responder com um 200 e inserir o livro', () => {
			return server
	      .post('/books')
	      .set(createAuthHeaders('post', url))
				.send(aBook)
	      .expect(200)
	      .then(() => {
					// Verifica que o livro foi inserido
	        expect(db.insertBook).toHaveBeenCalledWith(aBook)
	      })
		})
	})
})