Deveria haver testes de unidade para expressões regulares complexas?

Devo escrever testes de unidade para expressões regulares complexas no meu aplicativo?

• Por um lado: eles são fáceis de testar porque o formato de entrada e saída geralmente é simples e bem definido, e podem se tornar tão complexos que os testes específicos são valiosos.
• Por outro lado: eles próprios raramente fazem parte da interface de alguma unidade. Talvez seja melhor testar apenas a interface e fazer isso de maneira a testar implicitamente as regexes.

EDITAR:

Concordo com o Doc Brown, que em seus comentários de notas que este é um caso especial da unidade de teste de componentes internos .

Porém, como as regexes de componentes internos têm algumas características especiais:

1. Um regex de linha única pode ser realmente complexo sem realmente ser um módulo separado.
2. Regexes mapeiam entrada para saída sem efeitos colaterais e, portanto, são realmente fáceis de testar separadamente.

Testando o dogmatismo à parte, a verdadeira questão é se ele fornece valor ao teste de unidade de expressões regulares complexas. Parece bastante claro que ele fornece valor (independentemente de o regex fazer parte de uma interface pública) se o regex for suficientemente complexo, pois permite encontrar e reproduzir bugs e impedir regressões.

O Regex pode ser uma ferramenta poderosa, mas não é uma ferramenta em que você pode confiar para continuar funcionando se fizer alterações menores em regexes complexas.

Portanto, crie muitos testes que documentem os casos que devem ser abordados. E crie muitos testes que documentam os casos em que ele deve falhar, se for usado para validação.

Sempre que precisar alterar suas regexes, adicione os novos casos como testes, modifique sua regex e espere o melhor.

Se eu estivesse em uma organização que em geral não usasse testes de unidade, ainda escreveria um programa de teste que testaria qualquer regex que usaríamos. Eu faria isso no meu próprio tempo, se fosse necessário, meu cabelo não precisa perder mais cor.

Expressões regulares são código junto com o restante do seu aplicativo. Você deve testar se o código em geral faz o que você espera que ele faça. Isso tem vários propósitos:

• Teste são documentação executável. Isso demonstra claramente o que você precisa que o código faça. Se for testado, é importante.
• Os futuros mantenedores podem ter certeza de que, se o modificarem, os testes garantirão que o comportamento não seja alterado.

Como há um obstáculo extra a ser superado com o código em um idioma diferente incorporado ao restante, você provavelmente deve dar essa atenção extra em benefício da manutenção.

Em resumo, você deve testar sua inscrição, ponto final. Se você testar seu regex com testes automatizados que o executam isoladamente, como parte de uma caixa preta maior ou se você apenas mexe com ele manualmente, é secundário ao ponto em que você precisa garantir que ele funcione.

A principal vantagem dos testes de unidade é que eles economizam tempo. Eles permitem que você teste a coisa quantas vezes quiser agora ou em qualquer momento no futuro. Se houver algum motivo para acreditar que o seu regex será refatorado, ajustado, obterá mais restrições etc., sim, você provavelmente deseja alguns testes de regressão para ele ou, quando o alterar, precisará ir durante uma hora de reflexão sobre todos os casos extremos, para que você não o quebre. Isso, ou você aprende a viver com medo do seu código e simplesmente nunca o altera.

Por outro lado: eles próprios raramente fazem parte da interface de alguma unidade. Talvez seja melhor testar apenas a interface e fazer isso de maneira a testar implicitamente as regexes.

Eu acho que com isso você mesmo respondeu. Regexes em uma unidade provavelmente são um detalhe de implementação.

O que vale para testar seu SQL provavelmente também vale para expressões regulares. Quando você altera um pedaço de SQL, provavelmente o executa manualmente através de algum cliente SQL para ver se ele produz o que você espera. O mesmo vale para quando eu altero uma regex. Eu uso alguma ferramenta de regex com alguma entrada de amostra para ver se ela faz o que eu esperava.

O que acho útil é um comentário próximo ao regex com uma amostra de texto que ele deve corresponder.

Se você precisar perguntar, a resposta é sim.

Suponha que algum FNG apareça e pense que ele pode "melhorar" sua regex. Agora, ele é um FNG, tão automaticamente um idiota. Exatamente o tipo de pessoa que nunca deve tocar seu precioso código em nenhuma circunstância! Mas talvez ele esteja relacionado ao PHB ou algo assim, então não há nada que você possa fazer.

Só que você sabe que o PHB vai arrastá-lo chutando e gritando de volta para este projeto para "talvez dar ao cara algumas dicas sobre como você fez essa bagunça" quando tudo der errado. Então, escreva todos os casos que considerou cuidadosamente ao construir sua bela obra-prima da expressão.

E como você os anotou, você tem dois terços do caminho para ter um conjunto de casos de teste, já que - vamos ser sinceros - os casos de teste de regex ficam fáceis de executar depois que você constrói a estrutura.

Portanto, agora você tem um conjunto de condições de borda, alternativas e resultados esperados. E, de repente, os casos de teste são a documentação, conforme prometido em todas essas postagens do blog Agile também. Você apenas aponta para o FNG que, se a "melhoria" dele não passa nos casos de teste existentes, não há muita melhoria, é? E onde estão os novos casos de teste propostos que demonstram algum problema com o código original, que , como funciona, ele não precisa ser modificado, nunca !!!