O que os testes checam antes de publicar

Antes de o ipe.rest mudar, 137 pequenos testes o verificam no nosso próprio computador. Levam cerca de oito segundos, só sete deles rodam também a cada deploy, e há coisas que nenhum consegue ver. Aqui está o que eles olham.

O texto de ontem tratava de arquivos para máquinas. Este trata de algo que os leitores nunca encontram: as verificações que rodam antes de uma página ir ao ar. Os números são de 8 de novembro de 2026, tirados do repositório como ele estava antes de esta entrada ser adicionada: um comando, python3 -m unittest discover tests, 137 testes, todos aprovados.

Dez arquivos, um comando

Os testes ficam em dez arquivos, 1.850 linhas no total. A maior parte do peso está no diário: 56 dos 137 tratam de suas páginas. Outros 23 cobrem as demais páginas, como sobre, contato, privacidade e termos, e 18 cobrem a página inicial. O resto são grupos pequenos: 9 para as notificações aos mecanismos de busca, 8 para os dados estruturados, 7 para o deploy, 7 para a exibição dos horários, 4 para o service worker, 4 para os links e as versões dos recursos e 1 para a imagem de compartilhamento.

O que eles detectam

Muitas páginas daqui são geradas a partir das nossas fontes: as entradas do diário, o mapa do site, o feed, o llms.txt e os cartões da página inicial. Um teste falha se algum arquivo gerado estiver desatualizado, de modo que ninguém consegue editar um à mão e esquecer a fonte.

Outros testes cuidam dos idiomas. Cada entrada precisa ter uma versão em cada um dos doze idiomas, cada página precisa apontar para as outras e para si mesma, e o mapa do site precisa listar os mesmos links que a página. Outros cuidam das regras que nós mesmos definimos: uma entrada nova com menos de 300 palavras é recusada, uma com menos de 400 palavras só recebe um aviso, uma entrada com data no futuro é devolvida e a descrição de uma página não pode ser cortada com reticências.

O service worker, que permite abrir uma página sem conexão, tem um nome de cache que carrega um número de versão. Um teste verifica se a versão nos links de recursos de cada página é igual à que o service worker lista, para que uma folha de estilo alterada não seja entregue desatualizada.

Os sete que rodam a cada deploy

Só um arquivo, com 7 dos testes, roda no fluxo de deploy. Ele verifica o site já construído, não o repositório: se os arquivos de que um visitante precisa estão lá, se pastas como scripts e tests não são enviadas e se a página 404 está marcada como noindex e leva de volta à página inicial. Se falhar, o deploy para antes de qualquer coisa ser publicada.

Os outros 130 são um hábito, não uma barreira. Nós os rodamos antes de fazer o commit, e nada no servidor nos obriga a isso.

O que eles não conseguem ver

Um teste aprovado diz que as páginas concordam entre si, não que são boas. Nenhum teste lê as dez traduções rascunhadas por máquina para avaliar o sentido, e por isso essas páginas trazem um aviso de tradução por IA. Nenhum teste daqui abre um navegador, então o layout numa tela de celular estreita é conferido a olho. E não podemos dizer se algum rastreador percebe o cuidado que temos em manter esses arquivos em sintonia.

ipe(); // check the plain things, every time

Quase tudo o que mantém um site tranquilo tranquilo é monótono: uma contagem que bate, um link que resolve, uma versão que avançou. Preferimos que uma máquina confira isso por oito segundos a torcer para termos lembrado.