Douglas Figueiredo

[DevDouglasFigueiredo]

Os testes E2E foram desenvolvidos utilizando Playwright com TypeScript, seguindo o padrão Page Object Model (POM), com o objetivo de deixar os cenários mais organizados, reutilizáveis e fáceis de entender.

Ao longo do projeto, é possível perceber alguns trechos com repetição de código.

Tenho plena consciência da importância do princípio DRY (Don’t Repeat Yourself) em projetos de software. No entanto, em testes automatizados, optei por priorizar a legibilidade dos cenários e a clareza do que está sendo validado em cada teste.
A ideia foi deixar explícito o comportamento esperado em cada fluxo, mesmo que isso gere pequenas repetições.

Ou seja, a principal escolha aqui foi favorecer a compreensão do teste e do comportamento sendo validado, em vez de buscar a máxima reutilização de código.

Além dos testes E2E implementados, consideraria de suma importância a inclusão de testes de API responsáveis pelo envio dos dados para os gráficos no front-end.
A validação da API é importante para garantir que as resposta (estrutura, campos, tipos e valores esperados) permaneçam consistente, reduzindo o risco de falhas na interface causadas por alterações no backend.
Dessa forma, os testes de API complementam os testes E2E, permitindo identificar problemas de integração de forma mais rápida e confiável, antes que impactem diretamente no front-end.

Por fim, o projeto também conta com um pipeline no GitHub Actions e uma imagem Docker, com o objetivo de facilitar a execução e a validação do projeto.

O pipeline automatiza a execução dos testes, garantindo uma verificação rápida e padronizada a cada alteração no código.
Já a imagem Docker permite que qualquer pessoa execute o projeto em um ambiente controlado e padronizado, sem a necessidade de configurar manualmente todas as dependências.

⚠️ Atenção: Falhas Propositais no Pipeline (Bugs Encontrados)

Conforme solicitado nos requisitos ("Espera-se que os testes passem onde os critérios são atendidos e falham onde não estão"), este PR apresenta falhas reais evidenciados pela automação:

1. Teste deve exibir um cabeçalho com informações das maquinas: Falha pois o campo de tempo está sendo exibido como null min.
2. Teste deve exibir o tooltip com os valores ao repousar o mouse sobre o gráfico de Temperatura: Falha pois o componente de tooltip não é disparado neste gráfico específico.

Nota: O pipeline do GitHub Actions aparecerá como "Failed" no log final justamente para evidenciar esses bugs da aplicação.

Análise de Produto e Implementação

Respondendo aos critérios de avaliação sobre detalhes de implementação:

• O usuário pode completar essa jornada? Parcialmente. Embora os dados sejam exibidos, a ausência de tooltips no gráfico de temperatura e informações nulas no cabeçalho prejudicam a tomada de decisão técnica do usuário.
• Atende às especificações do protótipo? Não totalmente. O cabeçalho apresenta inconsistência de dados (null) e a interatividade prometida nos requisitos (tooltips para todos os gráficos) não foi cumprida no grafico de Temperatura.
• Comportamentos estranhos/inesperados:
  • O gráfico de temperatura não possui tooltip.

Relatorios

Para uma revisão detalhada, incluí os seguintes documentos no repositório:

• Bug Reports: report técnico dos bugs encontrados.
• Design Feedback: Análise de inconsistências entre os Requisitos e o Protótipo do Figma.

Relatorio da Execução dos Cenarios de Teste

[campofernando]

Hello @DevDouglasFigueiredo! Thanks for your submission. Just letting you know that we got your pull request and are in the process of reviewing it. We will soon provide you with our considerations.

[DevDouglasFigueiredo]

Hello @campofernando , thx for the position.