Teste unitário usando HTTP Mock em Go Lang
Há muito conteúdo online sobre testes unitários, mas talvez não muito exatamente sobre Go Lang em português, então vou direto ao que interessa e ao que talvez eu possa contribuir em algo.
Para começar, em poucas palavras, testes unitários são funções que testam outras funções. Estras outras funções são as funcionalidades da sua aplicação que definem o comportamento de cada parte da sua aplicação.
Testes unitários ajudam principalmente à:
1. Elevar a qualidade do código
Código testado da mais segurança a pessoa desenvolvedora fazer alterações em código já existente.
Quando um bug é identificado, é interessante concertar o bug criando um teste unitário que inicialmente falha/que reproduza o bug, e em seguida se atualize o código para corrigir o bug.
A cada atualização no código, é possível criar relatórios chamados de cobertura de teste. A cobertura de teste é apenas um número, e há que se tomar cuidado em não se tornar um obsessivo testando coisas inúteis que não adicionam valor ao teste. Mas de forma geral, é legal acompanhar esse número, cobertura de teste entre partindo de 70% é saudável.
Especificamente sobre o valor da cobertura de teste, há ferramentas que monitoram essa métrica, e seu time pode combinar um valor que vocês considerem saudável para se manter minimamente.
2. Identificar edge cases
Há condições da sua aplicação que não são tão óbvios, e que os experts do negócio/domínio não identificaram antes. Quando se cria testes unitários, o teste te faz pensar em outras possibilidades não pensadas antes.
Exemplo:
sua função valida a existência de determinado escopo em um token JWT
você recebeu a lista de escopos válidos do pessoal de negócio e seu teste unitário está passando com sucesso por todos eles: "web-origins email profile admin manager"
você pensa... e se... o token vier com o escopo "email:
você testa e PUTZ! seu código não está validando corretamente, "email:profile" não existe na lista de escopos permitidos e seu código permitiu a condição
nesse momento você atualiza seu código p/ que essa situação seja inválida
Esse é um cenário de problema real, no caso da aplicação fazer uma validação de token fraca, o token de outro client (client oAuth) pode gerar um escopo no formato descrito acima e acessar conteúdo que deveria ser protegido.
3. Fazer você pensar sobre o seu código sob a perspectiva do usuário
Como passamos muitas horas trabalhando para que o happy path (caminho feliz) aconteça na nossa aplicação, é comum não pensar como o usuário.
Esse vídeo(1min) é muito bom, e exemplifica bem o que quero transmitir:
Testes unitários deveriam:
ser fáceis de ler/entender
ser objetivos
testar pequenas partes
ser independentes
Ser Independentes ?
Ser independente significa que seu teste não deve depender de nada para funcionar. Mais especificamente, quando sua aplicação utiliza algum serviço externo, o serviço externo não deve ser invocado no teste.
Por exemplo, sua aplicação faz uma chamada a API da Netflix para listar os 10 filmes mais recentes. O seu teste unitário não deve depender da Netflix estar funcionando, mas sim utilizar um Mock, que é uma maneira de fazer com que o seu teste olhe para o Mock quando há uma chamada de API por exemplo.

O mesmo conceito se aplica a banco de dados, a serviço de autorização, entre outros, não se deve esperar que o teste unitário chame esses serviços externos ao seu código, para que eles funcionem. Mas porque ? O seu banco de dados já foi testado pelos desenvolvedores do banco de dados, a listagem de filmes da Netflix já foi testada pelo time da Netflix, eles funcionam e você não deveria testar essa condição. obs. lembre-se que teste unitário é diferente de teste de integração.
Em resumo, o seu teste unitário contendo um Mock de HTTP por exemplo, quando houver a necessidade de se requisitar algo externo a sua aplicação, o Mock pode fazer o trabalho de processar e responder essa requisição retornando os valores esperados pelo seu teste.
Exemplo:
seu teste unitário chamada a API da Netflix que retorna a listagem de 10 filmes recentes
você sabe que essa requisição deve retornar HTTP code 200 e com o body contendo algum conteúdo esperado em determinado formato (JSON geralmente).
então você adiciona o Mock HTTP no seu teste unitário
define o response (http.Response em Go) para que o HTTP code seja 200 (http.StatusOk) e tenha o body contendo o conteúdo/exemplo esperado.
Fiz um vídeo que vai do começo ao fim, explicando em detalhes o passo a passo em como se criar um Mock HTTP:
Se quiser ir direto ao ponto, aqui está o código.