Continuando com a nossa minissérie sobre como organizar e estruturar os testes unitários no Django, neste post vamos focar em testar nossas Views, aquela nossa amiga que faz o meio de campo entre o Template e o Model da nossa aplicação Django.

Primeiro passo

Se você já manja de testes unitários e está buscando só esclarecer algumas dúvidas tudo bem! Mas se você for iniciante no assunto, sugiro a leitura do primeiro post da minissérie para que você possa se contextualizar e aproveitar melhor essa segunda parte.

De qualquer forma, se você desejar, pode apreciar todos os posts ou os vídeos que estão no meu Canal do YouTube.

O que testar nas Views?

Bom, você pode começar testando o status code de retorno da requisição, por exemplo. Pode testar também o template que está sendo usado enfim. Como já falei no outro post, você pode e deve testar o comportamento esperado do seu código, é isso que um teste unitário deve garantir.

Para facilitar o entendimento e tornar nosso artigo mais prático, vamos implementar dois testes unitários para os exemplos citados no parágrafo anterior.

Show me the code!

from django.test import TestCase
from django.urls import reverse


class PessoaViewTestCase(TestCase):

    def test_status_code_200(self):
        response = self.client.get(reverse('pessoa_view'))
        self.assertEquals(response.status_code, 200)

    def test_template_usado(self):
        response = self.client.get(reverse('pessoa_view'))
        self.assertTemplateUsed(response, 'pessoa_view.html')

Toma! É código que você quer? 😀 #zueiraneverends

Falando sério agora, vou explicar cada um dos métodos da classe PessoaViewTestCase(), blz? Vamos começar pelo test_status_code_200(self), esse cara faz uma chamada a uma URL da nossa aplicação e espera/testa se ela realmente existe. Como que sabemos da certeza da existência de um recurso numa requisição web?

Porque a web funciona a base de requisições e respostas (request/response), esse é o comportamento padrão do protocolo HTTP, que é basicamente o cara responsável por garantir a comunicação entre um dispositivo e um site na internet, uma aplicação web enfim.

E em toda resposta, há entre outras coisas, um código que informa o estado daquele recurso, o código 200 é o que confirma a existência e disponibilidade do recurso/url acessada, sacou? A web é linda não é? 🙂

Linha por linha

A primeira linha do método, onde crio uma variável response e atribuo a ela o resultado da requisição feita pela instância da classe Client(), isso mesmo, o self.client.get() é a chamada propriamente dita a nossa URL que está montada pela função reverse() do Django, tudo bem até aqui?

Continuemos, a classe Client() ela simula a chamada como se você tivesse digitado a URL no navegador, só para facilitar o entendimento, quando isso acontece, teremos agora diversas possibilidades a serem testadas a partir da variável response.

Na linha seguinte, do primeiro método, confirmamos com o self.assertTrue() se o status code realmente é o que esperamos ser, informado como segundo parâmetro.

Perceba que essa explicação da chamada a URL vale pros dois métodos, em ambos usamos da mesma forma, o que difere no segundo método é que, agora, queremos averiguar qual o template a nossa view está usando, para isso, usamos o self.assertTemplateUsed() para fazer essa verificação, o nome do template que esperamos está sendo usado, está no segundo parâmetro também, segue sempre esse padrão.

Existem diversos métodos na suíte de testes do Django e do Python que podem ser usados para testar o que você deseja, se não me falha a memória, eu deixei uma lista desses cara no primeiro post da minissérie, já informado o link anteriormente aqui neste post.

Explicado a coisa toda, o próximo passo é rodar os testes, pra fazer isso abra um terminal, esteja claro, com seu ambiente virtual ativado e execute o comando ./manage.py test, com o comando anterior, você rodará todos os testes existentes no projeto, mas para rodar os testes somente de uma app, assim será mais rápido, especifique o nome da app Django no final, como em ./manage.py test core, por exemplo.

Leitura recomendada

Veja nesse site uma lista bem humorada dos status code que o protocolo HTTP disponibiliza e uma breve descrição de cada um, sempre que tenho dúvidas, uso ele como referência.

https://http.cat/

Mais uma leitura super recomendada, porém, bastante técnica, é a RFC do protocolo HTTP, vou deixar o link a seguir também, além dele, vou deixar outro que considero bem interessante, inclusive, quando estamos trabalhando com API Restful, precisamos muito desses cara! Se deseja aprender sobre API Restful com o Django, no Curso Django Pro você terá um módulo inteiro sobre isso, desde o básico até conceitos mais avançados como autenticação JWT.

https://tools.ietf.org/html/rfc2616
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status

Conclusão

Chegamos ao fim de mais um artigo, espero realmente ter adicionado mais conhecimento em você e como pode ver, Testes Unitários não é um bicho de sete cabeças e é divertido trabalhar com TDD (Test Driven Development).

Obrigado por ter chegado até aqui e ficaria muito feliz se puder contribuir com o artigo, comenta, compartilha enfim, isso certamente, mesmo que de maneira indireta pode te ajudar e me motiva também a continuar produzindo material de qualidade.

Um forte abraço e até o próximo post! XD