Como testar Django Rest Framework - Parte 1

Parte 1 da série Como testar Django Rest Framework. Nessa ...

latrova commited 1 ano, 9 meses ago
×

Introdução

Testar uma API pode ser bem diferente de testar algum outro tipo de aplicação, principalmente por que quando pensamos em APIs imaginamos chamadas e respostas, e embora isto esteja certo, não quer dizer que todos os seus testes devem ser assim. Devido a exemplos que a documentação do próprio framework disponibiliza dá a entender que todos os testes deveriam utilizar este formato:

No entanto, se você escrever todos os seus testes nesse formato, em pouco tempo você notará que o grau de complexidade e a quantidade de linhas cresce exponencialmente. O que dificulta a manutenção dos testes e torna mais difícil a leitura.

Devido a facilidade que o Django nos dá de criar uma base de dados exclusiva pra testes, a gente se esquece que estamos na verdade criando testes de integração, e não unitários! E o Django faz isso de forma tão rapida que parece natural escrever testes assim.

Não estou dizendo que você não deve ter nenhum teste neste formato, pelo contrário, você deve tê-los! O que estou dizendo é que devemos respeitar a nossa pirâmide:

A maior parte do nosso código deve ser validada através de testes unitários, enquanto uma parte menor através de testes de integração e uma parte ainda menor com testes funcionais (neste caso não se aplica).

Abordagem

Primeiro de tudo evitaremos testar coisas que não foram escritas por nós! Não precisamos testar se o Django funciona, pois já sabemos que sim.

Portanto, vou evitar a todo custo testes como:

Requisitos

Como visto nos exemplos acima, criaremos uma API para salvar movimentações financeiras (transactions). Faremos da maneira mais simples e rica possível, para que possa ser aplicado em outros cenários. Nessa primeira etapa do nosso tutorial vamos definir que:

  • Podemos listar, visualizar, criar, editar transação(ões) nos endpoints corretos.

Vamos começar?

1. Testar se as urls apontam corretamente

De acordo nossa regra, nós podemos listar, criar, editar, visualizar, deletar uma transação. Ações que poderão ser executadas através do enpoint /transactions. Logo, teremos as seguintes possibilidades

  • POST /transactions - para criação
  • GET /transactions - para listar
  • PUT /transactions/:id - para editar
  • GET /transactions/:id - para visualizar
  • DELETE /transactions/:id - para deletar

Segue nossos arquivos.

Usaremos o ModelViewSet do próprio DRF para simplificar, então vamos montar nossas urls:

Note a separação que fizemos entre as urls que possuem o :id específicado e não possuem. Isso determina, por exemplo, qual função invocar quando o GET é chamado neste endpoint.

A princípio, nosso objetivo será:

  • Identificar se quando o endpoint é chamado, a viewset correta é invocada.
  • Garantir que há diferença dos métodos (retrieve / list) chamados quando é passado um id no nosso endpoint.

Certo, mas como testar esse tipo de coisa? Se você ainda estiver com o mindset dos testes de integração, você vai continuar pensando em fazer alguns posts/gets para os endpoints e validar a resposta como 200/201/404.

Mas vamos mudar esse jeito de pensar e faremos assim!

Ótimo, já sabemos que nossos endpoints são direcionados para as views corretas, e que há distinção entre o list/retrieve. Mas precisamos testar ainda mais um ponto. Não tem sentido nenhum fazer um POST para um endpoint como /transactions/13, da mesma forma que não daria certo fazer um PUT para /transactions.

Vamos garantir que nossos endpoints estão com os métodos corretos configurados adicionando mais 2 testes.

E pronto, um rapido python manage.py test vai retornar uma mensagem de sucesso.

Atenção! Note como não estamos testando se as urls do Django funcionam, já sabemos que sim. Testamos apenas se nós mapeamos as nossas urls x views corretamente, e se não há falhas no nosso regex.

Parte 1 concluída. Aguarde próximos posts para continuarmos testando corretamente nossa api! :)

blog comments powered by Disqus