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

34

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 eles podem se tornar tão complexos, então testes específicos são valiosos.
  • Por outro lado: eles mesmos raramente fazem parte da interface de alguma unidade. Pode ser melhor testar apenas a interface e fazer isso de forma a testar implicitamente os regexes.

EDITAR:

Concordo com Doc Brown, que em seu comentário observa que este é um caso especial de teste unitário de componentes internos .

Mas, como os componentes internos, os regexes têm algumas características especiais:

  1. Um regex de linha única pode ser realmente complexo sem realmente ser um módulo separado.
  2. Regexe a entrada do mapa para saída sem efeitos colaterais e, portanto, é realmente fácil de testar separadamente.
por Lii 07.05.2016 / 12:29
fonte

6 respostas

102

Testando o dogmatismo de lado, a verdadeira questão é se ele fornece valor às expressões regulares complexas de teste de unidade. Parece bastante claro que ele fornece valor (independentemente de a regex ser parte de uma interface pública) se a regex é complexa o suficiente, já que permite encontrar e reproduzir erros e evitar regressões.

    
por 07.05.2016 / 13:10
fonte
21

O Regex pode ser uma ferramenta poderosa, mas não é uma ferramenta na qual você pode confiar para continuar trabalhando, mesmo que você faça pequenas alterações em regexes complexos.

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

Sempre que você precisar alterar suas regexes, adicione os novos casos como testes, modifique seu regex e espere pelo melhor.

Se eu estivesse em uma organização que, em geral, não usasse testes de unidade, eu ainda escreveria um programa de teste que testaria qualquer regex que usássemos. Eu faria até no meu próprio tempo se eu precisasse, meu cabelo não precisa perder mais cor.

    
por 07.05.2016 / 13:58
fonte
3

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

  • Teste é documentação executável. Isso demonstra claramente o que você precisa do código para fazer. Se for testado, é importante.
  • Os futuros mantenedores podem ter certeza de que, se modificá-lo, 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 para o benefício da manutenção.

    
por 08.05.2016 / 12:53
fonte
1

Em suma, você deve testar seu aplicativo, ponto final. Se você testa seu regex com testes automatizados que o executam isoladamente, como parte de uma caixa preta maior ou se você simplesmente toca com ele manualmente é secundário ao ponto em que você precisa ter certeza de que funciona.

A principal vantagem dos testes unitários é que eles economizam tempo. Eles permitem que você teste a coisa quantas vezes quiser agora ou em qualquer momento no futuro. Se existe alguma razão para acreditar que o seu regex será refatorado, ajustado, obterá mais restrições, etc., então sim, você provavelmente precisará de alguns testes de regressão para ele, ou quando mudar, você terá que ir através de uma hora de pensar em todos os casos de ponta, para que você não quebrasse. Isso, ou você aprende a viver com medo do seu código e simplesmente nunca o altera.

    
por 07.05.2016 / 16:43
fonte
-1

On the other hand: they themselves are seldom part of the interface of some unit. It might be better to only test the interface and do that in a way that implicitly tests the regexes.

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

O que vale para testar seu SQL provavelmente também vale para regexes. Quando você altera um pedaço de SQL, você provavelmente o executa manualmente por algum cliente SQL para ver se ele produz o que você espera. O mesmo acontece quando eu mudo um regex eu uso alguma ferramenta de regex com alguma entrada de amostra para ver se ele faz o que eu espero.

O que eu acho útil é um comentário perto do regex com uma amostra de texto que deve corresponder.

    
por 07.05.2016 / 12:57
fonte
-5

Se você tiver que perguntar, a resposta é sim.

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

Só que você sabe que o PHB vai arrastar você chutando e gritando de volta a este projeto para "talvez dar ao cara algumas dicas sobre como você fez essa bagunça" quando tudo correr mal. Então você anota todos os casos que você considera cuidadosamente ao construir sua bela obra-prima do expressiondom.

E desde que você escreveu todos eles, você tem dois terços do caminho para ter um conjunto de casos de teste, já que - vamos encarar - os casos de teste de regex são fáceis de serem executados quando você tem o estrutura construída.

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 , como prometido em todos os posts do Agile. Você apenas aponta para o FNG que, se a sua "melhoria" não passar nos casos de teste existentes, não é uma grande melhoria, não é? E onde estão seus novos casos de teste propostos que demonstram algum problema com o código original, que, desde que funciona, ele não precisa ser modificado, nunca !!!

    
por 08.05.2016 / 21:36
fonte