# Como Colocar Testes Instáveis em Quarentena Sem Esconder Bugs Reais

> A quarentena move testes sabidamente instáveis para fora do caminho bloqueante para que parem de derrubar builds, mantendo-os visíveis e rastreados para correção.

Source: https://latchkey.dev/pt/learn/ci-cd-concepts/how-to-quarantine-flaky-tests  
Updated: 2026-06-25

Quarentena é a disciplina de tirar um teste sabidamente instável do caminho que bloqueia merges sem excluí-lo - de modo que o build permaneça confiável enquanto você mantém o teste na lista para corrigir.

Quando um teste é comprovadamente instável, você tem três opções ruins (ignorá-lo, excluí-lo ou deixá-lo bloquear merges) e uma boa: quarentena. Feita corretamente, ela remove o ruído sem perder a coverage.

## Por que quarentena em vez de excluir ou repetir para sempre

Excluir um teste instável perde a coverage que ele fornece quando não está falhando. Repetir indiscriminadamente esconde regressões genuínas. Deixá-lo bloquear merges treina a equipe a ignorar builds vermelhos. A quarentena encontra o meio-termo: o teste ainda roda e reporta, mas seu resultado já não serve de gate para o merge.

## Como colocar em quarentena

- Marque o teste (por exemplo, um marcador `quarantine`/`flaky`) para que o runner o separe.
- Rode os testes em quarentena numa faixa não bloqueante que reporta mas não derruba o build.
- Abra um ticket de rastreamento vinculado ao teste no momento em que o colocar em quarentena.
- Mantenha o teste executando para que você colete dados de com que frequência ele ainda fica instável.

## Mantenha a honestidade

A quarentena deve ser temporária e visível, ou se torna um cemitério de coverage morta. Limite quanto tempo um teste pode ficar em quarentena, exponha a lista de quarentena num dashboard e exija uma decisão de corrigir-ou-excluir quando o prazo expirar. O princípio da gestão de instabilidade vale: contenha o ruído, nunca silencie o sinal.

## Promovendo de volta ou removendo

Quando o não determinismo raiz é corrigido, devolva o teste à suíte bloqueante e confirme que ele é estável ao longo de muitas execuções. Se ele não puder se tornar determinístico e não testar nada único, exclua-o deliberadamente - uma remoção honesta é melhor que um fantasma permanentemente em quarentena.

## FAQ

### What is How to quarantine flaky tests without hiding real bugs?

When a test is provably flaky, you have three bad options (ignore it, delete it, or let it block merges) and one good one: quarantine. Done right it removes the noise without losing the coverage.

### Why quarantine instead of delete or retry-forever?

Deleting a flaky test loses the coverage it provides when it is not flaking. Blanket-retrying hides genuine regressions. Letting it block merges trains the team to ignore red builds. Quarantine threads the needle: the test still runs and reports, but its result no longer gates the merge.

### Keep it honest?

Quarantine must be temporary and visible, or it becomes a graveyard of dead coverage. Cap how long a test may stay quarantined, surface the quarantine list on a dashboard, and require a fix-or-delete decision when the cap expires. The principle from flake management holds: contain the noise, never silence the signal.

### Promoting back or removing?

When the root nondeterminism is fixed, return the test to the blocking suite and confirm it is stable across many runs. If it cannot be made deterministic and tests nothing unique, delete it deliberately - an honest removal beats a permanently quarantined ghost.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt