A Motion HUB API é uma API desenvolvida em JavaScript utilizando o framework Fastify. Ela foi criada com o objetivo de praticar a construção de uma API de forma simples e eficiente. A API utiliza de um banco de dados em memória (in-memory database) para armazenar informações de filmes, como nome, descrição e duração. O projeto enfatiza boas práticas de desenvolvimento, incluindo padrões de código mantidos com ESLint e documentação gerada com Swagger.
Foi desenvolvido uma suite de testes que inclui testes manuais e automatizados usando Postman e Cypress, além de integrar tudo ao GitHub Actions para a execução contínua dos testes. Essa experiência me ensinou muito sobre a importância de uma documentação clara e do uso de testes automatizados para assegurar a qualidade do software.
BANCO DE DADOS EM MEMÓRIA
A Motion HUB API utiliza um banco de dados em memória, o que significa que não requer configurações complexas para armazenar e acessar dados rapidamente. No entanto, é importante notar que os dados são perdidos quando a aplicação é encerrada ou reiniciada, pois são mantidos apenas na memória volátil do servidor.
DOCUMENTAÇÃO
A documentação da API foi gerada utilizando o Swagger. Isso permite que qualquer desenvolvedor visualize e teste os endpoints da API de forma interativa. A documentação inclui descrições detalhadas dos parâmetros de entrada e saída, facilitando o entendimento do projeto a novas pessoas.
SwaggerUI do MotionHUB API
PLANO DE TESTES
Os cenários de teste foram desenvolvidos com base nas principais funcionalidades da MotionHUB API. Foram desenvolvidos um total de 13 casos de testes. Cada teste foi documentado com os seguintes detalhes:
😀 Status do Teste: Indicação se o teste foi aprovado ou reprovado.
🔥 Prioridade: Classificação da importância da funcionalidade no projeto.
🚨 Severidade: Grau de impacto sobre outras tarefas.
📆 Data do teste: Último dia que o teste foi realizado.
A criticidade dos bugs foi categorizada em quatro níveis, cada um refletindo a severidade do impacto no funcionamento do sistema e na experiência do usuário. Abaixo estão as definições de cada nível de criticidade:
🧊 Leve: Bugs que causam pequenos inconvenientes ou problemas estéticos, sem afetar significativamente a funcionalidade do sistema.
⚡ Moderada: Bugs que afetam algumas funcionalidades, mas possuem soluções alternativas, permitindo o uso contínuo do sistema.
🚨 Grave: Bugs que comprometem funcionalidades importantes, tornando o sistema difícil de usar ou causando erros significativos que afetam a experiência do usuário.
🔥 Blocker: Bugs críticos que interrompem completamente o funcionamento do sistema, impedindo a realização de ações essenciais e tornando o sistema inutilizável até serem corrigidos.
TESTES AUTOMATIZADOS
Os testes automatizados foram implementados para garantir uma cobertura contínua e eficiente dos cenários de uso da API.
A fim de estudos, desenvolvi os testes automatizados utilizando tanto Postman quanto Cypress. Em ambas as automações de testes, utilizei a biblioteca FakerJS para gerar massas de dados de forma dinâmica. Isso permite criar cenários variados e realistas, aumentando a robustez e abrangência dos testes.
Execução dos testes no Cypress
CONTINOUS INTEGRATION
Para garantir a qualidade contínua do projeto, integrei a suíte de testes automatizados do Cypress com o GitHub Actions. Toda vez que um push é feito no repositório, os testes são executados automaticamente, fornecendo feedback imediato sobre a saúde do projeto.
Pipeline do Github Actions
APRENDIZADOS
Desenvolver a Motion HUB API foi uma experiência divertida e mais fácil do que eu esperava. Aprendi a criar e organizar uma API eficiente, e a escolha do Fastify se mostrou acertada, tornando o projeto simples e eficaz.
Integrar o Swagger apresentou desafios, já que decidi adicioná-lo no final do desenvolvimento. A configuração inicial foi complicada, mas, uma vez pronto, o Swagger se tornou uma ferramenta valiosa para manter a documentação clara e acessível.
A implementação de testes também foi um ponto positivo. Criar um plano de testes ajudou a garantir a qualidade dos testes automatizados, e o uso do Postman e do Cypress me trouxe aprendizado, mesmo que tenha gerado alguma duplicidade.
Por outro lado, percebi que a falta de testes unitários foi uma falha. Não tê-los implementado desde o início me fez falta ao integrar os testes com o GitHub Actions, pois ter esses testes teria me dado mais confiança em manutenções e novas funcionalidades.
Experiências como essa são essenciais para entender a importância da qualidade do software e ajudam a desenvolver habilidades fundamentais para o mercado de trabalho.
