Build e testes¶
Os repositórios têm builds independentes. Execute a validação do serviço alterado e confira o resultado, em vez de inferir sucesso a partir da existência de arquivos em target/ ou de uma imagem antiga.
Java / Quarkus¶
Na raiz do serviço, com Java 21:
./mvnw.cmd test
./mvnw.cmd verify
No Linux, substitua por ./mvnw. test executa os testes associados à fase de teste; verify também empacota e executa as verificações configuradas no POM. Não é necessário executar ambos sempre: o primeiro deploy usa verify, que já inclui a fase test.
Confira o que foi executado. No JSON Handler, o POM define skipITs=true: verify executou 131 testes Surefire nesta validação, mas as fases Failsafe informaram testes pulados. Não apresente isso como teste de todos os serviços, teste nativo ou validação E2E da plataforma.
Os testes HTTP @QuarkusTest podem iniciar uma aplicação na porta de teste. Dependências usadas pelos testes variam: mocks, servidores temporários e bancos devem ser identificados em src/test, sem assumir que toda suíte é isolada.
Go¶
Com a versão requerida pelo go.mod, os comandos básicos são:
go mod download
go test ./... -cover
go build ./...
Router documenta geração de cobertura com go test -v -coverprofile=coverage.out -covermode=atomic ./.... Preserve flags próprias da pipeline ao reproduzir uma verificação de qualidade. Tags de integração e -race precisam ser avaliados no serviço que os utiliza; não os acrescente indiscriminadamente.
JVM e native são resultados diferentes¶
O pacote JVM usa target/quarkus-app/. O JSON Handler possui profile native, ativado por -Dnative ou -Pnative, que desabilita o JAR e habilita a imagem nativa. O compilador nativo e suas dependências precisam estar disponíveis; um executável Windows não serve de artefato Linux para o Dockerfile.
O build native não foi executado nesta jornada. Use Imagens Docker para conferir o artefato esperado por cada Dockerfile e não use -DskipTests para esconder uma suíte que falhou.
Evidência de sucesso¶
Registre comando, serviço, commit e resultados: quantidade de testes, falhas, testes pulados e artefato gerado. A aprovação local não comprova o quality gate remoto do Sonar nem uma implantação corporativa. Os resultados efetivamente executados estão no registro do onboarding.