Relatório de testes e validação do back-end (API)

1. Introdução

Nesse relatório, serão apresentados os testes realizados nas funcionalidades desenvolvidas na API do aplicativo Pet-feeder.

1.1 Contexto da API

A API foi toda desenvolvida em python, utilizando o framework Django rest_framework, com o intuito de que houvesse uma camada de negócio no back-end que recebe requisições HTTP do front-end, e se comunica diretamente com o banco de dados e com o Broker MQTT.

Dessa maneira, a API é responsável por processar, armazenar ou retornar dados do banco, bem como enviar e consumir mensagens no broker garantindo a comunicação com a ESP32.

1.2 Funcionalidades contempladas

1. Monitorar ração: sensor de nível, peso do pote e visualização de quantidades
   • Endpoint: POST /api/feed/monitor
2. Selecionar a quantidade de ração a ser dispensada
   • Endpoint: POST /api/feed/immediate-release
3. Agendar horário para dispensar ração
   • Endpoint: POST /api/feed/schedule
4. Visualizar a quantidade de água no reservatório
   • Endpoint: GET /api/water/reservoir
5. Retornar a quantidade de ração restante no pote após cada liberação
   • Endpoint: GET /report/food-quantity
6. Retornar histórico de alertas de água
   • Endpoint: GET /report/water-history
7. Notificar o usuário quando o reservatório de ração estiver abaixo de 25% da capacidade
   • Endpoint: GET /report/notification/low-level

2. Descrição das integrações com agentes externos

2.1 Integração com o Banco de dados

O banco de dados utilizado é um banco PostgreSQL, cujas tabelas e relacionamentos são inteiramente versionados e provisionados pelo por migrações do django.

Cada vez que uma nova model é criada dentro do projeto, representando uma entidade com atributos próprios (correspondentes a colunas na tabela no banco), essa model pode ser criada automaticamente dentro do banco por meio dos comandos são executados os comandos: - python manage.py makemigrations --noinput - python manage.py migrate --noinput Será criada uma migração automática no repositório com as alterações realizadas, as alterações são realizadas no banco.

Foi criado também uma classe utilizando a arquitetura singleton, para um conector direto com o banco, denominado database handler, que é utilizado para "re-utilizar" um cursor de conexão da biblioteca psycopg, ao longo de toda a aplicação e realizar queries diretas no banco.

2.2 Integração com o Broker MQTT

A integração com o broker MQTT é realizada utilizando a biblioteca Paho MQTT, configurando uma conexão segura via TLS com o broker HiveMQ Cloud. O cliente MQTT se inscreve no tópico feeder para receber mensagens, que são armazenadas em uma fila para processamento assíncrono. A cada 10 segundos, um job agendado processa as mensagens recebidas, decodificando os dados dos sensores e atualizando o banco de dados PostgreSQL com informações sobre o nível de ração, água e o timestamp de cada leitura. A comunicação e o processamento ocorrem em threads separadas para garantir eficiência e não bloquear o sistema.

2.3 Deploy da aplicação

Foi criado também um ambiente de deploy da aplicação na AWS, que será onde a infra-estrutura ficará provisionada em produção. Conforme a documentação já produzida quanto à arquitetura de infra, a aplicação está sendo executada em uma máquina virtual no serviço Amazon EC2, e está acessível para a internet, as integrações com o front-end já será realizada utilizando a API disponibilizada na AWS.

2.4 Infrastructure as code (Terraform)

Para provisionar a infra no ambiente da AWS, foi criado um novo repositório chamado aws-infra, que contém os arquivos terraform desenvolvidos para provisionamento da máquina virtual, e para implantar as aplicações do código terraform na AWS foi utilizado o software OpenTofu.

Abaixo estão algumas imagens de relato do status quo da infra-estrutura:

1. Código IaC:

2. Máquina EC2:

3. Request para o IP público da API:

OBS: A API retornou neste caso uma mensagem de que não existem dados, pois o banco não foi populado ainda no ambiente de cloud.

3. Testes

3.1 Metodologia de testes e roteiro

Por se tratar de uma API REST que disponibiliza endpoints para requisições de funcionalidades, os testes realizados foram todos feitos utilizando a ferramenta postman, e as atividades desenpenhadas em cada endpoint foram as seguintes:

1. Enviar a requisição para o endpoint x com os parâmetros e corpo de requisição esperados em cada caso
2. Verificar se a resposta recebida está de acordo com o esperado

3.2 Execução

3.2.1 POST /api/feed/monitor

• Requisição enviada:

  curl --location 'http://localhost:8000/v1/feed/monitor'
  

• Resultado esperado: Informações de ração no reservatório e pote.
• Resposta da API:

3.2.2 POST /api/feed/schedule

• Requisição enviada:

  curl --location 'http://localhost:8000/v1/feed/schedule' \
  --header 'Content-Type: application/json' \
  --data '{
      "device_id": 1,
      "quantity": 50,
      "time": "20:00",
      "days": ["monday", "tuesday"]
  }'
  

• Resultado esperado: Confirmação da criação de novo agendamento de liberação de ração na quantidade informada
• Resposta da API:

3.2.3 POST /api/feed/immediate-release

• Requisição enviada:

  curl --location 'http://localhost:8000/v1/feed/immediate-release' \
  --header 'Content-Type: application/json' \
  --data '{
      "device_id": 1,
      "quantity": 25
  }'
  

• Resultado esperado: Confirmação da criação de nova liberação imediata de comida na quantidade informada
• Resposta da API:

3.2.4 GET /api/water/reservoir

• Requisição enviada:

  curl --location 'http://localhost:8000/v1/api/water/reservoir/'
  

• Resultado esperado: Lista de quantidades e datas de liberação de comida do último ano
• Resposta da API:

3.2.5 GET /report/food-quantity

• Requisição enviada:

  curl --location --request GET 'http://localhost:8000/v1/report/food-quantity' \
  --header 'Content-Type: application/json' \
  --data '{
  "time_scale": "year"
  }'
  

• Resultado esperado: Lista de quantidades e datas de liberação de comida do último ano
• Resposta da API:

3.2.6 GET /report/water-history

• Requisição enviada:

  curl --location --request GET 'http://localhost:8000/v1/report/water-history' \
  --header 'Content-Type: application/json' \
  --data '{
    "time_scale": "day"
  }'
  

• Resultado esperado: Lista de quantidades registradas de água do último dia
• Resposta da API:

3.2.7 GET /report/notification/low-level

• Requisição enviada:

  curl --location 'http://localhost:8000/v1/report/notification/low-level'
  

• Resultado esperado: Notificação informando se o nível de água está acima ou abaixo de 25%, com indicação de criticidade da situação.
• Resposta da API:

4. Resultados obtidos

Na etapa atual do projeto, todos os endpoints necessários para que a integração com o Front-end seja realizada estão entregues e funcionais, o ambiente de cloud do projeto, também já está funcional e disponível para que a API possa ser acessada sem que os desenvolvedores de front-end precisem executar o ambiente localmente e a conexão da API com o banco e o Broker MQTT também estão plenamente funcionais.

5. Vídeos dos Testes Realizados