| Data de elaboração | 30/06/2026 |
| Responsável pelo estudo | Rodrigo Stefano Sales Nascimento (Assessor) |
| Equipe do estudo | CAOS |
| Alvo | Sistema Consignação — backend gov-consignacao-api (Java/Spring Boot) e frontend consignacao-frontend (Quasar/Vue 2) |
| Origem | Card CONSIG-773 — analisar o estado atual de testes automatizados e cobertura, frente à exigência do Sonar de no mínimo 80%. |
| Objetivo | Verificar o que existe implementado de testes, medir a cobertura real, identificar como ela é medida hoje e apontar o que falta para atingir os 80%, dimensionando a distância até a meta. |
O Sonar passou a exigir no mínimo 80% de cobertura de testes nos projetos. Cobertura é o percentual do código que é exercitado por testes automatizados ao rodar a suíte. Antes de planejar qualquer implementação, é preciso conhecer o ponto de partida: o que já existe de testes, qual a cobertura real e como ela é medida hoje.
O sistema Consignação tem dois projetos independentes, com stacks e ferramentais distintos:
gov-consignacao-api (Java / Spring Boot). Cobertura medida por JaCoCo.consignacao-frontend (Quasar Framework v1 / Vue 2). Cobertura mediria por relatório lcov.A pergunta central deste estudo é simples: quão longe estamos dos 80% e o que falta para chegar lá?
Análise feita sobre a branch
development, atualizada do repositório remoto.
Para o Sonar exibir cobertura, três elos precisam funcionar em cadeia:
Se qualquer elo falta, o Sonar não mostra cobertura — ou mostra zero. Este estudo verifica os três elos em cada projeto.
gov-consignacao-api)Um único teste em todo o projeto (ConsignacaoApplicationTests.java):
@SpringBootTest
class ConsignacaoApplicationTests {
@Test
void contextLoads() {
}
}
A ferramenta de cobertura (JaCoCo 0.8.8) já está configurada no pom.xml, porém somente com report — não há jacoco:check (não existe trava de threshold de cobertura no build):
<!-- JACOCO -->
<plugin>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution><goals><goal>prepare-agent</goal></goals></execution>
<execution>
<id>jacoco-report</id>
<phase>test</phase>
<goals><goal>report</goal></goals> <!-- só gera relatório -->
</execution>
</executions>
</plugin>
As dependências de teste (JUnit 5 + Mockito, via spring-boot-starter-test) estão presentes; o junit-vintage está excluído (ou seja, é JUnit 5 puro).
@SpringBootTest sobe todo o contexto Spring, o que exige um banco de dados real. O datasource vem de variáveis de ambiente (application.properties):
spring.datasource.url=${SPRING_DATASOURCE_URL}
spring.datasource.username=${SPRING_DATASOURCE_USERNAME}
spring.datasource.password=${SPRING_DATASOURCE_PASSWORD}
Sem essas variáveis no ambiente de teste, a criação do datasource (BancoDados.java) falha no boot, derrubando junto o Liquibase e a configuração de segurança/OAuth. O resultado do mvn test:
Tests run: 1, Failures: 0, Errors: 1
Caused by: java.lang.IllegalArgumentException: URL must start with 'jdbc'
Causa de fundo: não existe ambiente de teste isolado. A pasta src/test/resources não existe — sem profile de teste, sem banco em memória, sem mocks.
Mesmo com o teste falhando, o agente do JaCoCo grava o que foi exercitado. Materializei o relatório:
mvn -B test # roda o único teste (falha) e gera target/jacoco.exec
mvn -B jacoco:report # transforma o .exec em relatório (CSV/HTML)
Resultado agregado do jacoco.csv:
| Métrica | Coberto | Total | % |
|---|---|---|---|
| Instruções | 55 | 42.281 | 0,1% |
| Linhas | 10 | 9.496 | 0,1% |
| Branches | 0 | 3.029 | 0,0% |
As ~10 linhas cobertas são apenas resquícios da subida parcial do contexto (config de senha, datasource) antes de falhar. A cobertura efetiva é praticamente zero.
O backend tem ~230 classes. Distribuição principal:
| Pacote | Classes |
|---|---|
entidade |
45 |
repositorio |
41 |
servico (raiz) |
35 |
controlador |
30 |
servico/importacao |
20 |
constante |
13 |
| demais (visao, util, config, excecao, http…) | ~46 |
Para a meta de 80%, o foco realista são as ~89 classes com lógica de negócio (todas concretas — não há interfaces nessas camadas):
| Camada | Classes |
|---|---|
| Serviços (raiz + importação + util/auth/auditoria) | 59 |
| Controllers | 30 |
| Total prioritário | 89 |
Cobrir entidades (45) e repositórios (41) infla o número sem agregar valor (são getters/setters e interfaces de persistência). Por isso entram como exclusões no Sonar (seção 6).
consignacao-frontend)Nenhum teste. É o cenário mais cru dos dois. No package.json:
"scripts": {
"dev": "npx quasar dev",
"lint": "eslint --ext .js,.vue src",
"test": "echo \"No test specified\" && exit 0"
}
test é um placeholder que não roda nada..spec/.test.sonar-project.properties.Stack confirmada (define o ferramental de teste adequado): Quasar ^1.0.0 + @quasar/app ^1.0.0 (Quasar v1 = Vue 2), com vue-i18n@8 e vuelidate@0.7.
| Tipo | Arquivos |
|---|---|
Componentes .vue |
113 |
Scripts .js |
21 |
| Total | 135 |
Não é. O pipeline .gitlab-ci.yml só faz deploy — não há etapa de testes, de cobertura nem de análise no Sonar:
include:
- project: ci-cd/templates
file:
- deploy.ocp.yml
stages:
- deploy # única stage: nenhum build/test/sonar
Cruzando os três elos da seção 2:
| Elo da medição | Backend | Frontend |
|---|---|---|
| Testes que rodam | ❌ o único falha | ❌ não existem |
| Relatório de cobertura | JaCoCo configurado, mas sem teste válido | ❌ sem ferramenta |
| Publicação no Sonar | ❌ pipeline só faz deploy | ❌ pipeline só faz deploy |
Conclusão da medição: hoje não há cobertura sendo apurada no Sonar para nenhum dos dois projetos. O número real, medido localmente, é ~0%.
A distância até a meta é total nos dois projetos. O trabalho se divide em duas naturezas distintas:
⚠️ Sem a fundação, não existe onde escrever testes nem como medir — qualquer estimativa de “80%” feita agora seria um chute.
src/test/resources/application-test.properties) — elimina o erro URL must start with 'jdbc'.@WebMvcTest/@DataJpaTest) onde fizer sentido; @SpringBootTest completo no mínimo possível.sonar.coverage.jacoco.xmlReportPaths e definir exclusões (entidades, repositórios, config, constantes, classe main) para a meta ser viável e justa.@quasar/testing-unit-jest (quasar ext add @quasar/testing-unit-jest), que integra Jest + @vue/test-utils já configurado para o Quasar/Vue 2 — caminho de menor fricção, mais documentado e de melhor manutenção para esse stack.lcov e integrar ao Sonar via sonar.javascript.lcovReportPaths.Vitest seria a opção “moderna”, mas pressupõe Vite; o projeto é Quasar v1/webpack. Usá-lo exigiria plugins de compatibilidade e config manual — mais atrito, sem ganho real aqui.
.gitlab-ci.yml a execução de testes e a publicação da cobertura no Sonar (hoje só há deploy).O card CONSIG-772 — “Testes unitários para atualizações do Consignação” pede a cobertura de testes unitários (após as atualizações de CVE e do Java) para cumprir o Sonar. Como mostrado, ele não é executável no estado atual: não há suíte de testes funcional onde escrevê-los nem cobertura sendo medida. A ordem correta é:
A fundação de testes é, portanto, pré-requisito do CONSIG-772.
Conclusão: o sistema Consignação está praticamente sem cobertura de testes. O backend tem 1 teste, que falha, e cobertura medida de 0,1%; o frontend não tem framework nem testes (0%). O pipeline só faz deploy — não roda testes nem publica cobertura no Sonar. A distância até os 80% é total nos dois projetos.
Recomendação: tratar como dois esforços separados (stacks distintas) e em duas etapas:
@quasar/testing-unit-jest + lcov no Sonar; ambos com exclusões acordadas e cobertura publicada no pipeline.Só com a fundação pronta a cobertura passa a ser mensurável e a meta de 80%, planejável e estimável.