Testador de Regex

Como usar o Testador de Regex

1. 1Digite o padrão e as flags. Ex: padrão \d{3} e flag g para todas as ocorrências.
2. 2Cole o texto de teste. Os matches aparecem destacados automaticamente, a cada tecla.

Por que testar regex isolada, fora do código

Uma expressão regular é fácil de escrever errado de um jeito que só aparece em produção: uma âncora esquecida, uma classe de caracteres que aceita mais do que deveria, um quantificador guloso que captura demais. Testar a regex isolada, fora do contexto de uma função de validação inteira, ajuda a isolar exatamente esse tipo de problema, sem precisar rodar o sistema completo ou escrever um teste automatizado só para confirmar um padrão.

Este site já tem um post no blog detalhando erros comuns de regex para CPF e CNPJ que passam despercebidos em teste unitário — esta ferramenta é o companheiro natural desse tipo de investigação: cole o padrão suspeito e alguns exemplos de entrada (válidos e inválidos) para confirmar visualmente o que ele realmente casa.

Exemplo de código: a mesma lógica de match em JavaScript

const regex = /\d{3}\.\d{3}\.\d{3}-\d{2}/g;
const texto = 'CPF: 123.456.789-09 ou 987.654.321-00';

const matches = [...texto.matchAll(regex)];
matches.forEach((m, i) => {
  console.log(`#${i + 1}: "${m[0]}" na posição ${m.index}`);
});
// #1: "123.456.789-09" na posição 5
// #2: "987.654.321-00" na posição 24

As flags mais úteis para testar são g (global, encontra todas as ocorrências em vez de parar na primeira), i (ignora maiúsculas/minúsculas) e m (multiline, faz ^ e $ casarem início/fim de cada linha, não só do texto inteiro). Esta ferramenta sempre adiciona g automaticamente nos bastidores, mesmo que você não digite, porque sem ela o motor de regex do JavaScript pararia no primeiro match.

Casos de teste sugeridos para validar uma regex

Antes de considerar um padrão pronto, vale testar não só o caso feliz, mas também as entradas que tendem a expor falhas de projeto da expressão. Alguns exemplos de par entrada/expectativa para experimentar aqui:

• Uma string vazia — confirma se o padrão exige corretamente ao menos um caractere, ou se aceita indevidamente nada.
• O valor esperado cercado de texto extra (ex: um CPF no meio de uma frase) — mostra se falta uma âncora ^/$ que deveria restringir o match ao valor inteiro.
• Um valor quase certo, mas com um caractere a mais ou a menos — bom teste de particionamento de equivalência para os limites de quantificadores como {3} ou +.
• Múltiplas ocorrências no mesmo texto — confirma se a flag g está de fato encontrando todas, e não só a primeira.
• Caracteres especiais de regex presentes no próprio texto de teste (como . ou () — expõe padrões que deveriam ter escapado esses caracteres com \ e não escaparam.

Essa mesma lista serve de roteiro para escrever os casos de um teste automatizado depois de validar o padrão aqui: cada linha do texto de teste vira, em geral, uma asserção separada na suíte, cobrindo tanto o caminho feliz quanto as bordas que mais costumam quebrar silenciosamente em produção.

Perguntas Frequentes