Package br.com.xadm.comum.teste


package br.com.xadm.comum.teste
Fixtures de teste house-wide da casa (ADR 0019, raiz/001 Fase 5, plano 003 T3): Testcontainers de Postgres e Garage, o PostgresTestPropertyProvider que injeta a URL do container no Micronaut Test, e a fábrica de regras ArchUnit compartilhadas.

Consumido como testImplementation; as classes vivem em src/main para o app herdá-las no seu test classpath. Extração conservadora (R6): as fixtures Postgres/property-provider são byte-idênticas entre os apps; a GarageTestResource diferia só no nome do bucket (agora parametrizável por garage.test.bucket); o ArchitectureTest de cada app compõe RegrasArquitetura com suas regras próprias — a base não é achatada.

Postgres no teste: três receitas, e quando cada uma vale

O PostgresTestResource não é o caminho único — e nem o default. Escolha pela necessidade, não por adoção automática:

  1. jdbc:tc: — o default. App que só quer um Postgres real no @MicronautTest. Zero fixture, zero TestPropertyProvider, zero @TestInstance(PER_CLASS): o driver do Testcontainers já compartilha um container por URL por JVM — o mesmo ganho do PostgresTestResource. No application-test.yml:
    datasources.default.url: ${TEST_DB_URL:`jdbc:tc:postgresql:18:///db_auth`}
    datasources.default.driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver
    
  2. PostgresTestResource + PostgresTestPropertyProvider. App que precisa do handle do container — ler a porta, rodar SQL fora do datasource, withCommand de flag de servidor (ex.: wal_level=logical) — ou que não pode mexer no application-test.yml. Custo: implements PostgresTestPropertyProvider + @TestInstance(PER_CLASS) em cada classe de teste. Migrar para cá um app que já está na receita 1 é custo por ganho nulo.
  3. Nenhuma das duas — container dedicado, dito em voz alta. Teste que precisa de timeline de migration própria: migrar com Flyway até um target (VN), semear dado legado e só então aplicar VN+1, provando que o remap funciona sobre produção. Num container onde o Flyway do Micronaut já subiu em VN o cenário é impossível de montar (o CHECK novo barra os valores legados). Mesmo princípio já escrito em engenharia/java-micronaut.md §Testes para o wal_level: alvo que exige estado próprio sai do singleton.

ArchUnit: herde a regra E a prova de que ela rodou

Regra ArchUnit sobre import vazio passa verde testando nada. Por isso a fábrica entrega a defesa anti-vácuo junto: o ArchitectureTest que compõe RegrasArquitetura deve abrir pelo RegrasArquitetura.importNaoVazio(). O piso de versão que sustenta isso (archunit ≥ 1.4.1 no Java 25) é declarado pelo próprio módulo — quem herda o api(...) daqui já vem no piso, e não deve rebaixá-lo.

  • Class
    Description
    Helpers para testes de integração com PostgreSQL via Testcontainers (postgres:18-alpine).
    Sobe um único container Garage (object storage S3-compatível) para os testes de integração — análogo a PostgresTestResource.
    Declarada diretamente nas classes de teste (não só na superclasse), para o Micronaut Test aplicar TestPropertyProvider e sobrescrever o jdbc:... do application.yml.
    Sobe um único PostgreSQLContainer (postgres:18-alpine) compartilhado entre todos os testes de integração da mesma JVM.
    Fábrica das regras ArchUnit compartilhadas da casa.