API com Django 3: Aprofundando em testes e documentação

Tipos de testes - Apresentação

Olá! Meu nome é Guilherme Lima e eu serei o seu instrutor nesse treinamento de Django Rest, aprofundando em testes e documentação. O que vamos aprender nesse curso?

[00:109] Nesse curso vamos escrever uma série de testes automatizados para verificarmos os nossos modelos, nossos serializers, para verificarmos a autenticação de um determinado recurso, se é permitido ou não. Veremos como conseguimos escrever esses testes.

Vamos aprender também como documentarmos a nossa API para que outras pessoas consigam utilizar. Para quem é esse curso? Esse curso é super indicado para as pessoas que fizeram o curso anterior, de pré-requisito, de Django Rest; já vimos uma pincelada de teste. Nesse curso vamos nos aprofundar nesse conceito de testes.

Fazendo esse curso, vamos trabalhar e escrever uma série de testes: testes de autenticação, testes nos nossos modelos, testes no serializer e como executamos e escrevemos esses testes da melhor forma.

Falando da parte da documentação da nossa API que vamos desenvolver, vamos ter um recurso de programas e vamos ver como documentar esses programas utilizando o “Swagger”.

Então, fazendo esse curso nós vamos aprender uma série de coisas bacanas relacionadas a testes e documentação utilizando o Django Rest. Sabendo de tudo isso, vamos começar?

Tipos de testes - Conhecendo o projeto

Vamos iniciar os nossos estudos, então? Para começarmos, na atividade anterior a esse vídeo temos um passo a passo de como você vai baixar o projeto base que vamos utilizar para criarmos a nossa documentação, criarmos os testes da nossa API e aprofundarmos os nossos conhecimentos com o Django Rest.

Já segui todos os passos descritos nessa atividade e o que vou fazer agora vai ser subir o meu servidor, para nós entendemos melhor como está funcionando a nossa API. Então digito python manage.py runserver no aplicativo, com minha venv já ativada. Aperto a tecla “Enter” e vou abrir o localhost:8000.

Temos uma API de programas. Quando eu clico, ele pede que eu tenha um usuário de acesso. Na atividade também está descrito para criar um usuário, então vou colocar meu usuário gui e minha senha que ninguém imagina que é, 123. Vou apertar a tecla “Enter” e conseguir acesso à minha API.

Nesse projeto vamos trabalhar com uma API inspirada nos sistemas de streamers que temos, como Netflix, Amazon Prime, entre outros. Então na nossa API vamos ter um título, vamos ter um tipo, uma data de lançamento e a quantidade de likes. Essa vai ser a ideia da nossa API.

O que vou precisar fazer? Temos nossa API e queremos testar a nossa API, além disso, se clicamos em “Filtros”, observe que temos filtros para filtrarmos só o filme ou filtrarmos apenas as séries, e tem um campo de busca em que eu consigo pesquisar pelo título.

Todas essas informações, conseguimos observar no app “aluraflix > views.py”. Se observarmos esse teste, temos o nosso queryset de objetos, temos nossa classe de serializer e temos o filtro que eu mostrei para vocês.

Então vamos conseguir pesquisar pelo título do programa, seja ele um filme ou uma série. Temos um campo de busca no lugar do título, um filtro para identificarmos se vai ser um filme ou uma série e temos a nossa classe de autenticação, o BasicAuthentication. Isso ficou bem bacana, só que eu tenho 0 filmes.

Sempre quando vamos iniciar um projeto, seria legal se tivéssemos uma forma de carregarmos os dados iniciais - no nosso caso, os programas iniciais, sejam eles séries ou filmes. Existe uma forma de fazermos isso!

Vamos imaginar que estamos desenvolvendo nossa API e que o time que cuida do banco de dados já nos passou alguns programas iniciais. Então dentro do nosso app da “aluraflix”, temos uma pasta chamada “fixtures”. Quando eu clico nela, temos o objeto JSON, que se chama “programas_iniciais.json” e dentro temos um array com vários programas.

O primeiro programa então é aluraflix.programa- sempre identificamos o modelo que estamos trabalhando. Temos a chave primária, qual vai ser o id desse programa, os campos e seus respectivos atributos.

Então eu tenho: ”título”: “Coisas bizarras” - é uma série, tem a data de lançamento, quantidade de likes e quantidade de dislikes. Eu tenho essa informação para todos os outros filmes e séries.

Então tem: “Coisas bizarras”, “O Bruxo”, “Emília em São Francisco”, “Corações de lata”, “Le Le Lend”, “Saltadores Ultimato” e grandes sucessos da “aluraflix”. Qualquer semelhança com um filme real é coincidência mesmo.

Então tenho esses programas, tenho esse arquivo JSON. Como que eu faço para carregar esses arquivos JSON na minha base de dados? Abrindo o meu terminal, vou pará-lo e, o que vou fazer? Existe um comando para eu carregar os dados, o nome é muito parecido com o que falamos mesmo: loaddata, ou seja, “carrega os dados”. Agora vou passar qual é o arquivo que eu quero carregar os dados.

Poxa, está em JSON e vamos fazer nosso projeto utilizando o Python, o Django! Como ele vai entender do JSON para o Django, como ele nos faz essa ponte? Esse método tem essa responsabilidade. Na próxima atividade eu vou deixar um link para nós entendermos melhor como essa função funciona.

Então, loaddata. Vou passar que eu quero carregar programas_iniciais.json. Quando eu aperto a tecla “Enter”, olhe o que vai acontecer: ele fala que foi instalado novos objetos de uma fixture(s). Então tem algo importante para eu passar para vocês.

Observe que dentro da pasta do meu app, eu tenho uma pasta chamada “fixtures”, dentro dessa pasta eu tenho um arquivo JSON com os dados que eu quero carregar, os iniciais. Para eu conseguir carregar esses dados, eu só executo o comando loaddata do manage.py e passo o nome do arquivo JSON.

Vamos supor que no meu modelo da “aluraflix” eu tenha, além de programas, diretores, roteiristas e várias outras classes de modelo. O que eu poderia fazer? Poderia criar um outro arquivo JSON para preencher esses modelos.

E aqui eu faço a referência, que nesse caso é o programa - mas se fosse os diretores eu escreveria aluraflix.diretores e passaria qual é id e quais são os campos com seus dados. Para eu carregar, só passo o nome dele depois do loaddata.

Carreguei, mas será que carregou mesmo? Vamos ver! Vou subir o meu servidor mais uma vez. Quando eu venho no programa e atualizo, temos “Coisas bizarras”, “O bruxo”, “Corações de lata”, “Resgate do soldado Carlinhos” e vários outros filmes bem legais também, “Capitão Bahia”. Filmes de sucesso da “aluraflix”.

Qual é o nosso desafio agora? Podemos conferir, por exemplo, se eu colocar o filtro de “Série” no campo “Tipo” e enviar que eu quero ver só as séries, eu tenho: “Coisas bizarras”, “O bruxo” e “Emília em São Francisco”. Se eu coloco, por exemplo, “Filme” no campo “Tipo” e enviar, temos só os filmes: “Corações de lata”, “Le Le Lend” e “Saltadores ultimato”. Isso ficou bem bacana!

Se eu pesquisar também, por exemplo, por “Saltadores” e dar uma busca, verei só aquele filme “Saltadores ultimato”. Isso ficou bem legal! Aparentemente a nossa API está funcionando, porém é importante que garantamos que partes diferentes da nossa API estejam funcionando. Vamos entregar o comportamento que esperamos. Por isso a importância dos testes.

Nas próximas aulas vamos aprofundar mais ainda nesse conhecimento dos testes, a importância dele e como testamos diferentes partes da nossa API.

Tipos de testes - Tipos de testes

Lembra, no nosso curso anterior em que realizamos o teste para verificarmos a requisição get, a requisição post e a requisição init? Aquele teste poderia ser feito por uma pessoa. Eu poderia contratar uma pessoa, um amigo meu e falar: “teste, faça uma requisição get e me fale o que acontece. Anote o que acontece” e a pessoa iria anotando.

Nos testes automatizados, o que garantimos? Garantimos que a máquina vai cumprir as etapas do script que passamos e garantimos os determinados resultados esperados. Caso um resultado não dê certo, aquele teste falhe e podemos identificar o porquê da falha.

Então dentro deste mundo de testes automatizados, existe um teste chamado “teste de unidade”. Qual o objetivo dele? É testar métodos e funções individuais.

Se observarmos na nossa aplicação, nós temos um modelo, um serializer, nossa view; então eu quero testar o modelo. Por exemplo: no nosso modelo, observe que temos os campos titulo e tipo, porém entre esses campos existem alguns valores default. Então caso eu não passe nenhum valor de like ou dislike, o valor default deles será 0.

Então eu poderia criar um teste para verificar se de fato esse valor default está sendo executado. Isso seria um teste de unidade, em que eu queira testar apenas o modelo – ou que eu queira testar agora se o serializer está serializando os campos corretos. Então eu poderia realizar um teste só no meu serializer.

Não estou pegando a minha API e fazendo uma requisição get para testar todos os campos, estou testando uma parte única da minha aplicação. Quando falamos em parte única, eu vou testar funções e métodos individuais. Chamamos esse teste de “teste de unidade”.

Existe um segundo teste, que é o “teste de integração”. O que é o teste de integração? Ele visa testar diferentes módulos ou serviços usados em uma aplicação. Então se pararmos para pensar, em nossa aplicação Django Rest, nossa API, nós temos a API e o banco de dados. Esse banco de dados pode ser SQLite, MySQL ou PostgreSQL, não importa, ele é uma outra aplicação que interage com a aplicação do Django Rest.

Então se eu quero testar, por exemplo, se eu consigo ter acesso ao banco de dados ou se eu consigo salvar no banco de dados alguma coisa, ou recuperar uma determinada informação do banco de dados - nós chamamos esse teste de “teste de integração”.

Eu tenho a minha aplicação, o módulo principal, só que esse módulo interage com outros módulos - como, por exemplo, o banco de dados. Então se eu faço um acesso a um banco de dados, se eu quero fazer uma verificação de alguma informação no meu projeto e, para isso, eu vou precisar acessar o banco de dados, nós vamos chamar esse teste de “teste de integração”.

Existe um outro teste também, chamado de “teste funcional”. Qual é o objetivo do teste funcional? É testar o requisito do negócio, então ele vai se concentrar em verificar a saída de uma ação, verificar se eu consigo ter acesso a algumas informações ou ao fluxo que um cliente vai ter dentro da nossa aplicação.

Esse teste funcional pode gerar uma certa confusão com o teste de integração, então vou exemplificar de uma forma bem simples. Podemos pensar que o teste de integração, que vimos anteriormente, visa consultar o banco de dados. Então eu tenho a minha aplicação e quero consultar o banco de dados.

Já o teste funcional, eu quero fazer um teste para verificar se eu consigo obter um valor especifico do banco de dados, conforme definido no nosso teste. Então esse seria um teste funcional, diferente de um teste de integração.

Dentre esses testes, eu deixo um desafio para você pesquisar outros tipos de testes. Além do teste de unidade que falamos, existe o teste de integração, teste de aceitação - e todos esses são conhecidos como testes funcionais.

Existem outros tipos de testes também, chamados de “testes não funcionais”. Qual é o objetivo desses outros testes? É realizar outros tipos de testes não relacionados a como o nosso sistema foi feito, mas a ambientes diferentes para o nosso sistema - cenários diferentes e externos à nossa aplicação. Como por exemplo, um teste de estresse - qual o objetivo? É submeter o nosso software às situações extremas.

Então eu vou testar os limites da minha aplicação e avaliar como ela se comporta, ou vou um teste de carga. Eu quero verificar o limite de dados processados pela minha aplicação e tentar enxergar até quando a minha aplicação suporta.

Ou um teste de desempenho/performance, onde eu quero verificar, por exemplo, como o sistema se comporta em diferentes cargas. Ou qual é o comportamento do nosso software em diferentes cenários externos a ele. Então esses são conhecidos como testes não funcionais.

O que eu vou fazer? Nas próximas atividades eu vou deixar um link com algumas leituras extras em relação a esse mundo de testes e nas próximas aulas nós vamos começar a botar a mão na massa e vamos aprender como testamos a nossa API, para garantirmos o controle e o funcionamento da nossa aplicação da forma desejada.

Sobre o curso API com Django 3: Aprofundando em testes e documentação

O curso API com Django 3: Aprofundando em testes e documentação possui 91 minutos de vídeos, em um total de 39 atividades. Gostou? Conheça nossos outros cursos de Python em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Tipos de testes
• Testes de unidade
• Teste de integração
• Testando a API
• Documentando a API com Swagger