E2E Test Backlog - Praxis Metadata Starter

Objetivo

Consolidar uma suite E2E interna do praxis-metadata-starter antes da migracao de consumidores externos, usando fixture canonica em src/test/java/org/praxisplatform/uischema/e2e/fixture.

Estado atual

Perfis

• e2e-h2: implementado e validado
• e2e-pg: pendente; ainda nao existe dependencia de Testcontainers ou PostgreSQL no pom.xml

Validacoes focais oficiais atuais

Sprint E2E final de consistencia/negativos/override em H2:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-final-e2e ^
  -Dtest=MutableResourceLifecycleE2ETest,CapabilityConsistencyE2ETest,WorkflowNegativePathsE2ETest,CapabilityE2ETest,ActionCatalogE2ETest,SurfaceCatalogE2ETest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest,GlobalExceptionHandlerTest test

Resultado validado:

• BUILD SUCCESS
• 59 testes
• fecha o cross-check entre /capabilities e os catalogos dedicados de surfaces/actions em escopo COLLECTION e ITEM
• endurece caminhos negativos de workflow para payload invalido e IDs inexistentes, incluindo ausencia de efeito parcial em bulk-approve
• prova override e ordering reais de SurfaceAvailabilityRule no container, no mesmo nivel ja coberto para actions
• corrige um gap estrutural do starter: o pom.xml agora publica spring-boot-starter-validation, garantindo que @Valid nos controllers canonicos realmente produza 400 Validation error no runtime HTTP
• adiciona prova E2E de que POST /employees invalido falha canonicamente, confirmando que a correcao de validacao nao ficou restrita a endpoints de workflow

Hardening transversal de repetibilidade e concorrencia leve:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-transversal-hardening ^
  -Dtest=AnnotationDrivenSurfaceDefinitionRegistryTest,AnnotationDrivenActionDefinitionRegistryTest,CapabilityServiceTest,CapabilityE2ETest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest test

Objetivo deste corte:

• validar que os registries lazy de surfaces e actions constroem snapshot uma unica vez mesmo sob lookup concorrente leve
• provar que /capabilities e DefaultCapabilityService permanecem deterministas em chamadas repetidas para o mesmo contexto
• endurecer o starter para uso enterprise sem alterar contrato publico nem abrir novo eixo funcional

Cobertura inicial da Fase 5 de WorkflowAction em H2:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase5-actions ^
  -Dtest=ActionCatalogE2ETest,AnnotationDrivenActionDefinitionRegistryTest,ActionCatalogServiceTest,DefaultActionAvailabilityEvaluatorTest,SurfaceCatalogE2ETest,AnnotationDrivenSurfaceDefinitionRegistryTest,AbstractResourceControllerJpaWriteIntegrationTest test

Resultado validado:

• BUILD SUCCESS
• 44 testes
• abre o catalogo global/contextual de actions, valida a separacao surface vs workflow, prova execucao tipada real com POST /employees/{id}/actions/approve e POST /employees/actions/bulk-approve, e cobre a availability composicional por contexto, RBAC e estado do recurso em escopos ITEM e COLLECTION

Hardening adicional da availability de actions no mesmo nivel final da Fase 4:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase5-actions-availability ^
  -Dtest=ActionCatalogE2ETest,ActionCatalogServiceTest,DefaultActionAvailabilityEvaluatorTest,DefaultActionAvailabilityContextResolverTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest,AnnotationDrivenActionDefinitionRegistryTest,SurfaceCatalogE2ETest,AnnotationDrivenSurfaceDefinitionRegistryTest,AbstractResourceControllerJpaWriteIntegrationTest test

Resultado validado:

• BUILD SUCCESS
• 50 testes
• actions agora usam availability composicional por ActionAvailabilityRule, com short-circuit no primeiro deny, metadata incremental e cobertura para:
  • resource-context-required
  • missing-authority
  • resource-state-blocked
  • resource-state-unavailable
  • ausencia de vazamento de metadata de estado apos deny por RBAC
  • wiring plugavel da auto-configuracao por lista de regras

Primeiro corte validado da Fase 6 de capabilities unificadas:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase6-capabilities ^
  -Dtest=OpenApiCanonicalCapabilityResolverTest,CapabilityServiceTest,CapabilityE2ETest,AbstractResourceControllerJpaWriteIntegrationTest,SurfaceCatalogE2ETest,ActionCatalogE2ETest,ApiDocsControllerTest test

Resultado validado:

• BUILD SUCCESS
• 61 testes
• fecha o primeiro corte do snapshot unificado com:
  • GET /{resource}/capabilities
  • GET /{resource}/{id}/capabilities
  • agregacao de operacoes canonicas + surfaces + actions
  • cobertura para recurso mutavel, recurso read-only, fixture E2E real e piloto JPA interno
  • regra explicita de que CapabilitySnapshot.group segue o grupo OpenAPI canonico resolvido por resourcePath, normalmente o grupo individual do recurso

Fechamento de ActionScope.COLLECTION na Fase 5:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase5-actions-collection ^
  -Dtest=ActionCatalogE2ETest,ActionCatalogServiceTest,AnnotationDrivenActionDefinitionRegistryTest,DefaultActionAvailabilityEvaluatorTest,DefaultActionAvailabilityContextResolverTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest,SurfaceCatalogE2ETest,AnnotationDrivenSurfaceDefinitionRegistryTest,AbstractResourceControllerJpaWriteIntegrationTest test

Resultado validado:

• BUILD SUCCESS
• 54 testes
• fecha o discovery contextual GET /{resource}/actions, o caso real POST /employees/actions/bulk-approve e a convivencia correta entre escopos ITEM e COLLECTION

Cobertura adicional que fecha a Fase 4 de surfaces em H2:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase4-availability ^
  -Dtest=SurfaceCatalogE2ETest,AnnotationDrivenSurfaceDefinitionRegistryTest,DefaultSurfaceAvailabilityContextResolverTest,DefaultSurfaceAvailabilityEvaluatorTest,SurfaceCatalogServiceTest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,AbstractResourceControllerJpaWriteIntegrationTest test

Resultado validado:

• BUILD SUCCESS
• 32 testes
• fecha o catalogo global e contextual de surfaces, a availability por composicao, o guardrail contra N+1 por surface e o wiring plugavel basico por regras

Hardening adicional da Fase 4 em src/test:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-phase4-exhaustive-tests ^
  -Dtest=SurfaceCatalogE2ETest,AnnotationDrivenSurfaceDefinitionRegistryTest,DefaultSurfaceAvailabilityContextResolverTest,DefaultSurfaceAvailabilityEvaluatorTest,SurfaceCatalogServiceTest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,AbstractResourceControllerJpaWriteIntegrationTest test

Resultado validado:

• BUILD SUCCESS
• 39 testes
• endurece explicitamente:
  • resource-state-unavailable
  • short-circuit sem vazamento de metadata apos deny por RBAC
  • ordenacao, not found, conflito de valor canonico e caching por grupo no SurfaceCatalogService
  • publicacao automatica de surfaces mutaveis vs. read-only e exclusao de mappings workflow-like no registry

Baseline do Sprint 1 em H2:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-e2e ^
  -Dtest=MutableResourceLifecycleE2ETest,ReadOnlyResourceE2ETest,SchemaDiscoveryE2ETest,OpenApiGroupRegistrationE2ETest,LegacyCoexistenceE2ETest,GlobalExceptionHandlerTest test

Resultado validado:

• BUILD SUCCESS
• 23 testes
• fixture interna subindo com o starter auto-configurado, sem wiring manual extra para docs, scanner e exception handling

Corte mais recente do Sprint 3 em H2:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-e2e-stats ^
  -Dtest=OptionsAndOptionSourcesE2ETest,StarterBootstrapE2ETest,StatsE2ETest,LimitsAndErrorsE2ETest test

Resultado validado:

• BUILD SUCCESS
• 4 testes
• prova separacao explicita entre fixture enriquecida para option-sources e bootstrap puro do starter para recurso novo + docs canonicos
• fecha a superficie estatistica canonica do core resource-oriented em H2, incluindo caminhos 200, 400, 501, /schemas/filtered e /schemas/catalog

Fixture compartilhada

Implementada em:

• src/test/java/org/praxisplatform/uischema/e2e/fixture/E2eFixtureApplication.java
• src/test/java/org/praxisplatform/uischema/e2e/fixture/E2eFixtureEntities.java
• src/test/java/org/praxisplatform/uischema/e2e/fixture/E2eFixtureDtos.java
• src/test/java/org/praxisplatform/uischema/e2e/fixture/E2eFixtureResources.java
• src/test/java/org/praxisplatform/uischema/e2e/fixture/E2eFixtureDataSupport.java
• src/test/resources/application-e2e-h2.yml

Recursos cobertos pela fixture:

• EmployeeController no novo core (AbstractResourceController)
• PayrollViewController no novo core read-only (AbstractReadOnlyResourceController)
• DepartmentController no novo core (AbstractResourceController)
• LegacyEmployeeController no core legado (AbstractCrudController)

Sprint 1 - indispensaveis

Implementado:

• MutableResourceLifecycleE2ETest
• ReadOnlyResourceE2ETest
• SchemaDiscoveryE2ETest
• OpenApiGroupRegistrationE2ETest
• LegacyCoexistenceE2ETest

Escopo validado no Sprint 1:

• ciclo canonico do recurso mutavel
• superficie HTTP query-only do recurso read-only
• /schemas/filtered sobre controllers novos
• grupos OpenAPI individuais, agregados, application e praxis-metadata-infra
• coexistencia temporaria entre core novo e legado no mesmo app

Achados canonicos corrigidos durante a implementacao do Sprint 1:

• PraxisMetadataAutoConfiguration nao estava registrando automaticamente o pacote org.praxisplatform.uischema.rest.exceptionhandler, o que fazia hosts apoiados apenas no starter perderem o tratamento global de erros
• GlobalExceptionHandler nao tratava NoResourceFoundException, fazendo endpoint inexistente cair como 500 em vez de 404
• GlobalExceptionHandler nao tratava HttpRequestMethodNotSupportedException, fazendo PUT e DELETE sem mapping cair como 500 em vez de 405
• /schemas/filtered em cenarios E2E exigiu blindagem de query string para paths com /{id}, reforcando o contrato canonico por path + operation + schemaType

Arquivos centrais endurecidos por esses achados:

• src/main/java/org/praxisplatform/uischema/configuration/PraxisMetadataAutoConfiguration.java
• src/main/java/org/praxisplatform/uischema/rest/exceptionhandler/GlobalExceptionHandler.java
• src/test/java/org/praxisplatform/uischema/e2e/AbstractE2eH2Test.java
• src/test/java/org/praxisplatform/uischema/rest/exceptionhandler/GlobalExceptionHandlerTest.java

Sprint 2 - robustez funcional

Implementado e validado:

• CatalogDiscoveryE2ETest
• LimitsAndErrorsE2ETest
• ResourceQuerySurfaceE2ETest
• HateoasAndPayloadSizeE2ETest

Achados canonicos corrigidos ao abrir o Sprint 2:

• DomainCatalogController passou a usar application como fallback real quando a consulta chega sem group e sem path, eliminando o grupo sintetico api
• DynamicSwaggerConfig deixou de registrar grupos agregados com wildcard amplo derivado de /; agora publica pathsToMatch explicitos por recurso do grupo
• DynamicSwaggerConfigTest foi isolado por @Profile para nao poluir o @SpringBootTest da fixture E2E

Ainda pendente: - nenhum teste adicional de Sprint 2 em H2

Achados canonicos corrigidos ao fechar o Sprint 2:

• o recurso piloto employees agora cobre navegacao positiva de cursor e locate, permitindo validar o backlog de query surface sem depender do consumidor externo
• LimitsAndErrorsE2ETest passou a manter o caminho 501 Not Implemented sobre o recurso read-only payroll-view, separando explicitamente o caso suportado do nao suportado
• a fixture E2E agora valida que praxis.hateoas.enabled=false remove links top-level e item-level, enquanto recursos read-only continuam sem links de escrita mesmo com HATEOAS ligado

Sprint 3 - corporativos avancados

Implementado e validado:

• OptionsAndOptionSourcesE2ETest
• StarterBootstrapE2ETest
• StatsE2ETest

Observacoes do estado atual:

• o Sprint 3 agora prova o runtime de options e option-sources na fixture H2, incluindo a exposicao metadata-driven de x-ui.optionSource em /schemas/filtered
• o bootstrap puro do starter agora esta validado para recurso novo + /schemas/filtered + /schemas/catalog + grupos OpenAPI usando E2eBootstrapFixtureApplication, sem beans manuais extras para docs, scanner ou query core
• a cobertura de option-sources continua usando fixture enriquecida com beans locais para OptionSourceQueryExecutor, OptionSourceEligibility e OptionSourceRegistry; isso ficou explicitamente separado do bootstrap puro para nao misturar capacidade opcional com subida basica do starter
• StatsE2ETest agora cobre COUNT, SUM, AVG, MIN, MAX, distribuicao HISTOGRAM e TERMS, alem de ETag/If-None-Match e variacao estrutural com includeInternalSchemas em schemas de stats

Pendente:

• perfil e2e-pg com PostgreSQL e Testcontainers
• smoke mais amplo de bootstrap full-context alem dos testes focais de auto-configuracao, apenas se o consumidor piloto exigir

Regra atual de avanco

Nao migrar consumidor externo enquanto a fixture E2E do starter nao estiver verde e documentada no minimo para o Sprint 1.

Proximo gate obrigatorio

Antes de migrar um consumidor externo, a base minima do starter deve incluir:

• Sprint 1 verde em H2
• QA independente da rodada, com foco em integridade de codigo, logica de negocio e uso corporativo
• backlog do Sprint 2 priorizado sobre a mesma fixture
• plano explicito para e2e-pg, sem tratar H2 como substituto definitivo de cenarios enterprise

Gate de Prontidao Pre-Piloto

O comando oficial minimo de validacao pre-piloto, no estado atual do starter, e:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-final-e2e ^
  -Dtest=MutableResourceLifecycleE2ETest,CapabilityConsistencyE2ETest,WorkflowNegativePathsE2ETest,CapabilityE2ETest,ActionCatalogE2ETest,SurfaceCatalogE2ETest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest,GlobalExceptionHandlerTest test

Complemento recomendado de hardening transversal:

mvn -Dproject.build.directory=D:\Developer\praxis-plataform\praxis-metadata-starter\.codex-build-transversal-hardening ^
  -Dtest=AnnotationDrivenSurfaceDefinitionRegistryTest,AnnotationDrivenActionDefinitionRegistryTest,CapabilityServiceTest,CapabilityE2ETest,OpenApiUiSchemaAutoConfigurationSurfaceAvailabilityTest,OpenApiUiSchemaAutoConfigurationActionAvailabilityTest test

O Que Pode Ficar Fora do Primeiro Consumidor

Nao precisa bloquear o primeiro piloto real por:

• e2e-pg com PostgreSQL/Testcontainers
• stress mais agressivo de concorrencia/caches lazy
• suite integral do modulo

Esses itens continuam sendo hardening transversal desejavel, mas nao sao gate minimo para sair do starter.

Estado de readiness para a proxima fase

• Fase 4 de surfaces esta encerrada no starter
• a Fase 5 de WorkflowAction esta formalmente encerrada no starter
• a Fase 6 de capabilities esta formalmente encerrada no starter
• o backlog E2E remanescente nao bloqueia mais a migracao do primeiro consumidor; ele agora endurece infraestrutura adjacente