Pular para o conteúdo principal

Testes de arquitetura

Verificações automáticas que garantem que o código respeita as fronteiras de camadas e convenções do projeto (DDD na Prod-API, separação frontend/backend).

Objetivo​

Falhar o build ou o pipeline quando:

  • uma camada referencia outra que não deveria (ex.: Production.Domain a importar EF ou controllers);
  • namespaces ou pastas violam a matriz de dependências acordada;
  • novos padrões proibidos aparecem (ex.: acesso direto a DbContext fora de Production.Infra.Data).

Backend (.NET)​

Ferramentas comuns:

  • NetArchTest.Rules — regras declarativas em C# (“tipos em Production.Domain não devem depender de Microsoft.EntityFrameworkCore”).
  • ArchUnitNET — estilo similar, com fluent API.

Exemplos de regras alinhadas ao AGENTS.md:

  • Production.Domain não referencia Production.Infra.Data, Production.Application, Production.API.
  • Production.Application não referencia DbContext nem pacotes EF.
  • Production.API não instancia repositórios concretos sem passar por DI dos serviços de aplicação.

Os testes ficam num projeto de testes (pode ser o existente Production.Domain.Tests ou um Production.Architecture.Tests dedicado) e executam com dotnet test.

Frontend​

Opções complementares (menos padronizadas que no .NET):

  • ESLint com eslint-plugin-import e regras no-restricted-imports para impedir imports de pastas internas (ex.: páginas a importarem diretamente DbContext não aplica — mas pode impedir pages/ a importarem de legacy/).
  • dependency-cruiser para grafos e regras de arquitetura em JS/TS.

CI​

  • Executar testes de arquitetura na mesma etapa que dotnet test (ou job dedicado rápido).
  • Falha deve citar a regra violada e o tipo ficheiro envolvido para correção rápida.

Adicione exemplos concretos de regras NetArchTest/ArchUnit quando o primeiro teste de arquitetura for integrado na solução.