Série: Recolocação e teste prático Java

Episódio 07: Fechando o teste prático: checklist final de uma API Java bem entregue

Episódio 07: Entrega final

Quando o último endpoint não basta

A entrega de um teste prático não termina quando o último endpoint responde. É quando outra pessoa abre o projeto, roda, testa no Swagger, olha o H2 e entende as decisões em poucos minutos — o tipo de fechamento que fecha o arco março–abril de 2026 com dignidade técnica.

Na visão geral, o produto não é só bytecode: é o pacote “clonar → rodar → validar”, com manual de arranque em README.md e checklist alinhados ao PDF:

Visão geral
Avaliador / CI Sistema entregue
(API + doc + dados)
Manual de arranque
README.md + checklist

O produto final não é só bytecode: é o pacote “clonar → rodar → validar”.

O problema por trás da etapa

O enunciado costuma exigir compilação, execução correta e um manual de arranque no repositório — em geral o ficheiro README.md — com comando para subir, Swagger e acesso ao banco. Na avaliação entram organização, clareza da arquitetura, separação de responsabilidades, boas práticas e código legível. Consolidação final olha funcionamento e apresentação técnica ao mesmo tempo.

Checklist: Java 17+, Spring Boot, OpenAPI, REST, JPA/Hibernate, H2, Flyway, Bean Validation, CRUD completo, paginação, 400 em validação, controllers finos, e um README.md que sirva de manual de arranque honesto e completo. Cada “sim” reduz risco.

Na revisão mental, três blocos de execução — Git, build/JVM e dados efémeros — guiam quem clona o repo:

O que corre na máquina
Repositório Git
(fonte + SQL)
Build + JVM
(Spring Boot)
H2 + artefactos
em memória

Três frentes lógicas na cabeça do avaliador: código, runtime e dados efémeros.

A decisão técnica

O README.md funciona como manual de arranque e carta ao avaliador: objetivo, tecnologias, pré-requisitos, comando para subir, URLs do Swagger e do console H2, credenciais. Seção curta de arquitetura (Web, Application, Domain, Infra) e bloco de decisões técnicas (por que Spring Boot, Flyway com H2, handler global, etc.).

O checklist do PDF mapeia para quatro pilares técnicos — cada um com evidência no repositório:

Pilares da revisão
Web + OpenAPI
testável
Application
regras claras
Domain
modelo estável
Infra + Flyway
schema auditável

Checklist do episódio espelha estas quatro caixas: cada uma com evidência no repo.

Implementando com critério

Rode o fluxo inteiro como primeira vez: migration aplicada, cadastro via Swagger, listagem, get por id, update, delete, casos inválidos; confirme linhas no H2. Revise pacotes por classes deslocadas (controller chamando repository direto é cheiro de alerta).

Extras só se não quebrarem simplicidade: testes automatizados ou endpoint auxiliar podem valorizar; auth ou multi-tenancy sem necessidade podem roubar tempo na banca.

Na última milha da entrega, ficheiros e rotinas manuais provam que alguém fechou o loop antes do commit:

Artefactos que fecham a prova
README.md
manual de arranque · run + URLs
pom.xml / Gradle *Application.java Testes manuais
Swagger + H2

Última milha: o avaliador encontra comando, entrypoint e duas URLs sem perguntar no e-mail.

Fechamento da série

A narrativa completa: ler o PDF → base Spring → domínio → persistência → aplicação → web/Swagger → manual de arranque (README.md) e checklist. Não é só API de veículos; é demonstração de pensamento de engenharia em escala pequena — exatamente o que processos seletivos em 2026 ainda compram quando bem feitos.

Prepare um pitch de dois minutos: objetivo, stack, camadas, fluxo de uma requisição e como rodar. Se você explica com calma, o código costuma estar alinhado.

Como defender essa etapa

Entrega é competência: um manual de arranque fraco no README.md faz projeto bom parecer pior. Checklist liga cada item do PDF a evidência no repositório. Falhas claras e previsíveis valem mais que “nunca erro” opaco.

Reflexão final: Da recolocação ao commit final, o que permanece é o hábito de ler antes de codar e de entregar como quem respeita o tempo do avaliador.


Nota: Cenário anonimizado; série de insights técnicos reutilizáveis (Fiction-Based Technical Insights).

Christian Mulato
Engenheiro Construtor

© 2026 Christian Mulato. Todos os direitos reservados.