---
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.