Ignored Test.

Um teste existe na suíte mas está permanentemente impedido de executar. Ele ainda conta como um "teste" no arquivo, mas contribui com zero verificação. Fique atento a marcadores de skip/ignore, blocos com prefixo x, corpos vazios e código de teste enterrado em comentários — muitas vezes acompanhados de uma desculpa vaga como "flaky" ou "fix later".

// modificadores skip/disabled — nunca rodam
describe.skip('checkout flow', () => { /* ... */ });
it.skip('applies the discount', () => { /* ... */ });
test.todo('handles expired coupons');

// com prefixo x (jasmine/jest/mocha) — mesmo efeito
xit('rejects negative amounts', () => { /* ... */ });
xdescribe('payments', () => { /* ... */ });

// teste comentado — invisível para o executor E para o relatório
// it('retries on 503', async () => {
//   await expect(client.fetch()).resolves.toBeOk();
// });

// JUnit: @Ignore / @Disabled com um motivo vago
@Ignore("disabled for now as this test is too flaky")
@Test public void peerPriority() { /* ... */ }

Sinais reveladores no relatório de testes: uma contagem não nula de "skipped"/"pending" que ninguém olha, suítes que encolheram silenciosamente ao longo do tempo e skips sem issue vinculada ou prazo de expiração. returns condicionais no início de um teste (if (process.platform === 'win32') return;) são uma variante mais sorrateira que esconde o skip completamente dos contadores de skip.

Por que acontece

• Um teste começou a falhar (uma regressão real, uma dependência de tempo instável, uma mudança de ambiente/versão) e pulá-lo foi a maneira mais rápida de obter um build verde ou desbloquear um merge.
• Um teste foi escrito antes da implementação (test.todo/xit como placeholder) e nunca foi retomado.
• Migrações (novo framework, runtime ou API) quebraram o teste e ele foi estacionado "temporariamente."
• O skip deveria durar uma tarde; sem lembrete, prazo de expiração ou issue de acompanhamento, ele se torna permanente.

Por que prejudica

• Falsa confiança. Um teste pulado parece cobertura no arquivo e no diff do PR, mas não exercita nada. O caminho de código que ele afirmava proteger agora está desprotegido, e todos assumem que está seguro.
• Apodrecimento (bit rot). Um teste ignorado nunca é compilado junto (em algumas linguagens), nunca é refatorado e nunca é atualizado. Quanto mais tempo fica parado, mais ele se distancia da realidade, até que reabilitá-lo custe mais do que reescrevê-lo.
• Regressões ocultas. O bug ou o comportamento instável que motivou o skip ainda está lá — apenas foi silenciado. Pular trata o sintoma (uma barra vermelha) em vez da doença.
• Ruído e erosão. Contagens permanentes de "pulados" treinam a equipe a ignorar o relatório de testes, o que deixa novos skips passarem despercebidos. Código de teste morto e comentado também acrescenta sobrecarga de leitura e manutenção sem benefício algum.

Trate cada teste ignorado como uma decisão que deve ser tomada agora, não adiada indefinidamente.

1. Faça a triagem de cada skip. Para cada teste desabilitado/comentado/todo, decida: corrija-o, apague-o ou coloque-o em quarentena com um prazo de expiração e uma issue rastreada. "Deixar pulado para sempre" não é uma opção.
2. Corrija e reabilite se o comportamento ainda importa. Se o teste é instável, corrija a instabilidade (controle tempo, aleatoriedade, assincronismo e estado compartilhado) em vez de pular.
3. Apague-o se a funcionalidade acabou ou o teste está obsoleto. Um teste apagado é honesto; um pulado mente. O controle de versão se lembra dele caso você precise de volta — então nunca comente um teste em vez de apagá-lo.
4. Se você precisar pular temporariamente, faça isso de forma evidente e com prazo definido: sempre inclua um motivo e um link de acompanhamento, e prefira um mecanismo que apareça nos relatórios e falhe assim que o prazo passar, para que o skip não possa apodrecer.
5. Estanque o sangramento com lint/CI. Ative uma regra de "nenhum teste desabilitado" para que novos skips sejam pegos na revisão, e trate a contagem de skips existente como um backlog a ser reduzido a zero.

// antes — silencioso, permanente, não rastreado
it.skip('refunds the full amount on cancel', async () => {
  await expect(refund(order)).resolves.toEqual({ amount: 100 });
});

// depois — corrigido e rodando de novo (causa-raiz: total em ponto flutuante)
it('refunds the full amount on cancel', async () => {
  await expect(refund(order)).resolves.toEqual({ amount: 100 });
});

// intermediário aceitável — visível, atribuído e com expiração
it.skip('refunds the full amount on cancel — flaky clock, see JIRA-1234 (remove by 2026-07-01)', async () => {
  /* ... */
});

// antes
@Ignore("too flaky")
@Test public void peerPriority() { ... }

// depois: corrija a dependência de tempo e reabilite, ou apague se obsoleto
@Test public void peerPriority() { ... }