O teste técnico da Ília consistiu no desenvolvimento de um servidor http de gerenciamento de cartão ponto. Basicamente há duas rotas /v1/folhas-de-ponto (GET) e /v1/batidas (POST), são responsáveis, respectivamente, por gerar relatório mensal do cartão ponto e criar uma nova batida. Embora seja um sistema simples, busquei utilizar arquitetura limpa para que o código seja de fácil compreensão e escalável, permitindo o aumento de sua complexidade. A pasta dominio é onde estão todas as regras de negócio, enquanto que a infra é parte específica para servidor web e persistência. Para simplificar o projeto, a persistencia é feita de forma local infra/relogio-em-memoria.repositorio.ts, entretanto, pode ser facilmente alterada para utilizar banco de dados. Já para o servidor web foi utilizado framework NestJS.
Programei todo o projeto em português para seguir o padrão que foi solicitado na documentação da API.
git clone https://github.com/lva98/Ilia-Technical-Testcd Ilia-Technical-Testdocker build -t ilia-technical-test .docker run -p 3000:3000 --name ilia-technical-test -it ilia-technical-test
- Para teste de integração execute
docker exec -it ilia-technical-test pnpm test:e2e - Para teste unitário execute
docker exec -it ilia-technical-test pnpm test
Ao utilizar a arquitetura limpa houve um desacoplamento das regras de negócio, dessa forma, propiciando a criação de testes unitários no domínio da aplicação. Basicamente, os testes unitários consistem em validar as regras de negócio implementadas nos casos de uso bater-ponto.caso-de-uso e gerar-folha-ponto.caso-de-uso. Além disso, alguns testes unitários foram criados para validar relogio-em-memoria.repositorio que está na camada de infraestrutura.
- Disparar erro ao não informar entrada
- Disparar erro ao informar entrada inválida
- Não deve cadastrar horário sábado ou domingo
- Não deve permitir cadastrar o mesmo horário
- Não deve haver mais que 4 pontos cadastros por dia
- Disparar erro ao tentar cadastrar menos que uma 1 de intervalo de almoço
- Deve permitir cadastrar 1 hora de almoço
- Deve calcular corretamente o relatório com horas excendentes
- Deve calcular corretamente o relatório com horas devidas
- Deve poder cadastrar 4 pontos em ordem
- Deve poder cadastrar 4 pontos fora de ordem e ordená-los
- Deve retornar uma lista vazia quando não é cadastrado ponto
- Deve retornar a lista de pontos cadastrada no dia especificado
Os testes de integração consistiram em subir o servidor e validar o funcionamento das rotas. Sua implementação pode ser encontrada em test/epp.e2e-spec.ts. Basicamente são testadas as duas rotas disponíveis no servidor web.
/v1/batidas (POST), cria uma nova batida, assim verificando se a rota está em funcionamento como o esperado/v1/folhas-de-ponto (GET), busca uma folha de ponto e verifica se a rota respondeu corretamente os valores
Esse projeto seguiu a risca a documentação da API solicitada, assim, toda informação necessária estará descrita no arquivo api.yaml que pode ser aberto no Swager Editor.