-
Status do intake: implemented-pending-homologation
-
Data: 2026-08-31
-
Origem: falha na etapa
Run PHPUnit (Backend Tests)do workflow de releaserelease-gestor.yml(run 33406223200) -
Classificação: estabilidade de testes unitários, isolamento de schema
-
Batch: BATCH-152
1. O sintoma
No workflow GitHub Actions de release (release-gestor.yml), a suíte de testes do PHPUnit falhou na asserção:
1) CssProcedenciaGravacaoTest::testHelperDegradaComSegurancaSemSchema
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-''
+'v1:41f3cbfce667ec3b36e89157e6b4aafebf5f160e'
tests/Unit/PHP/CssProcedenciaGravacaoTest.php:902. A causa
-
Na esteira de CI/Release, a etapa
Run Phinx migrationsexecuta previamente todas as migrações no banco de dados MySQL de testes, criando a colunacss_source_hashnas tabelas de recursos (paginas,layouts, etc.). -
O teste
testHelperDegradaComSegurancaSemSchematem como objetivo testar a degradação graciosa (quando o banco ou a colunacss_source_hashainda não existem), chamando:gestor_css_procedencia_para_recurso('<div class="flex"></div>', '', '', 'paginas') -
A função
gestor_css_procedencia_para_recursoconsultagestor_schema_campo_existe('css_source_hash', $tabela). -
Sem o mock explícito do cache de schema
$_GESTOR['schema-campos'], a função consulta o banco de dados real ativo onde a migração já ocorreu. Como a coluna já existe no banco de teste, a função gera a assinatura válida'v1:...'em vez de retornar''.
3. A correção
Isolar o estado de teste em CssProcedenciaGravacaoTest.php:
-
No método
testHelperDegradaComSegurancaSemSchema, salvar e forçar explicitamente$_GESTOR['schema-campos']['paginas.css_source_hash'] = falsepara simular o cenário sem schema (antes da migração), restaurando o estado original após a asserção. -
Adicionalmente, testar com uma tabela que comprovadamente não possui o campo (ou tabela inexistente), garantindo a cobertura de degradação tanto com simulação de ausência de campo quanto de tabela.