bQUARKz
35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
80 lines
2.4 KiB
Markdown
80 lines
2.4 KiB
Markdown
---
|
|
id: AGD-0067
|
|
ticket: multi-frontend-architectural-tests
|
|
title: Testes arquiteturais para fronteiras multi-frontend
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [compiler, compiler-general, studio, frontend, architecture, tests, multi-frontend]
|
|
---
|
|
|
|
# Agenda - Criar testes arquiteturais
|
|
|
|
## Objetivo
|
|
|
|
Domain owner: `compiler/general`, com impacto em `studio` e `vm-arch`.
|
|
|
|
Definir testes que protejam fronteiras: backend comum sem PBS, IR comum sem AST PBS, Studio comum sem instanciacao PBS fora do composition root e runtime neutro.
|
|
|
|
## Contexto atual
|
|
|
|
O repo ja tem testes Java para backend, bytecode e IRVM. ArchUnit pode ser util, mas o alinhamento proibe adicionar biblioteca arquitetural quando testes simples bastarem.
|
|
|
|
## Escopo
|
|
|
|
- Escolher ferramenta minima.
|
|
- Definir regras por pacote.
|
|
- Adicionar testes que sejam baratos e claros.
|
|
|
|
## Fora de escopo
|
|
|
|
- Cobrir toda arquitetura do monorepo.
|
|
- Adicionar ArchUnit sem justificativa concreta.
|
|
- Bloquear referencias PBS em testes PBS ou no frontend PBS.
|
|
|
|
## Arquivos e componentes a inspecionar
|
|
|
|
- `build.gradle.kts` e version catalog se houver.
|
|
- `prometeu-compiler/prometeu-build-pipeline/src/test/java/...`
|
|
- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/test/java/...`
|
|
- `prometeu-studio/src/test/java/...`
|
|
- pacotes runtime/PVM quando presentes
|
|
|
|
## Alteracoes propostas
|
|
|
|
Opcao A: testes Java/reflection simples para imports, nomes de tipos e packages publicos.
|
|
|
|
Opcao B: ArchUnit caso a quantidade de regras e modulos justifique.
|
|
|
|
Recomendacao inicial: comecar com testes simples; reavaliar ArchUnit se as regras virarem frageis.
|
|
|
|
## Estrategia de implementacao
|
|
|
|
Definir allowlist de packages PBS, composition root e testes PBS. Escrever verificacoes independentes por dominio para falhas legiveis.
|
|
|
|
## Testes necessarios
|
|
|
|
- Backend/common nao importa `frontend.pbs`, `parser.pbs` ou `semantic.pbs`.
|
|
- IR comum nao expoe tipos PBS.
|
|
- Studio comum nao instancia servicos PBS fora da allowlist.
|
|
- Runtime nao usa nomenclatura ou semantica PBS.
|
|
|
|
## Criterios de aceitacao
|
|
|
|
- Regras rodam no build local.
|
|
- Falhas apontam arquivo/pacote responsavel.
|
|
- Excecoes autorizadas estao documentadas.
|
|
|
|
## Riscos
|
|
|
|
- Teste textual produzir falso positivo por docs ou fixtures.
|
|
- Criar barreira rigida antes de definir provider e lifecycle.
|
|
|
|
## Decisoes que devem ser registradas
|
|
|
|
- Ferramenta escolhida.
|
|
- Allowlist de packages.
|
|
- Ordem de introducao das regras.
|
|
|