Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity
prometeu-studio/discussion/workflow/agendas/AGD-0067-multi-frontend-architectural-tests.md
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.
Details
Test / Build skipped: 15, passed: 601
Details
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
Details
multi FE adjustment agendas
2026-07-15 07:58:23 +01:00

2.4 KiB
Raw Blame History

id ticket title status created resolved decision tags
AGD-0067 multi-frontend-architectural-tests Testes arquiteturais para fronteiras multi-frontend open 2026-07-15
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.