Desenvolvimento Pró-Ativo, testes e suas ferramentas (Pex)

Há muito tempo escrevi um post falando da minha visão sobre 3 pontos interessantes em relação a debugging. E neste novo post eu gostaria de destacar o terceiro item, “Desenvolvimento Pró-ativo”:

“Como Edsger Dijkstra citou, se debug é o processo para remover os bugs, programar é o processo para criá-los. Partindo deste pensamento, por que não evitar os bugs? Por que não programamos pensando em evitar bugs, além de resolver os problemas do negócio? Muitos destes bugs ocorrem por falta de um simples if (obj != null), por incrível que pareça!”

E apesar de ter publicado o post em novembro de 2007, este problema parece ser algo “normal” em toda fase de desenvolvimento de um projeto. E já que não conseguimos evitar bugs através de desenvolvimento pró-ativo, temos então que utilizar ferramentas que minimizem a possibilidade destes erros.

Testes – Caixa Branca

Existem algumas técnicas de testes que são extremamente importantes, mas para o contexto deste post temos que entender apenas a técnica da caixa branca.

Segundo o wikipedia, “Teste de caixa-branca é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte. No teste de hardware, cada nó de um circuito pode ser testado.

Difere do teste de caixa-preta, em que a perspectiva interna do sistema é desconsiderada, sendo testadas e mensuradas somente as interfaces do sistema. Entretanto, ambas as técnicas podem ser usadas em conjunto, no que é chamado teste de caixa-cinza. Dessa forma, o teste é modelado conhecendo-se a estrutura interna do sistema, mas a execução ignora esse aspecto, como na caixa-preta.”

Basicamente o teste da caixa branca consiste em testar a sua implementação, não interessa em qual fase do desenvolvimento.

Porém, para aplicar um teste de caixa branca adequado, temos que utilizar algumas técnicas para identificar possíveis casos de testes para aquela código em específico. E é aqui que se encaixa o Pex, da Microsoft Research.

Pex – Automated White box Testing for .NET

Pex nada mais é que um “gerador automático de entrada para testes”. 
Segundo sua documentação, teste unitário está se tornando muito popular nos últimos anos. E isso se confirma pela abordagem da Microsoft em seus projetos, como ASP.NET MVC por exemplo.

O conceito básico para o Pex envolve o conceito de Teste Unitário Parametrizado. Este tipo de teste é muito parecido com o teste unitário comum, porém a única diferença é que ao invés de especificar valores fixos para o teste, é possível determinar uma série de valores e obter o resultado geral do teste de acordo com cada valor informado na entrada.

O funcionamento do Pex é extremente simples.

Primeiro passo é criar o documento de testes relacionado ao Pex. Para isto, abra a classe que deseja testar e clique com o botão direito, selecionando a opção Pex > Create Parameterized Unit Test Stubs. Isto irá criar uma classe de testes que cobrirá todos os testes de sua classe através de teste unitário parametrizado.

Com o arquivo de teste criado, basta clicar – ainda na classe que será testada – em Run Pex, e analisar o resultado dos seus testes.

Você poderá notar, entre outras coisas, todos os parâmetro de entrada e o resultado da execução do seu método:

Conclusão

Este tipo de ferramenta é extramemente útil em qualquer contexto de desenvolvimento. Reduzir tempo na construção dos testes, ao mesmo tempo que se mantém a garantia do software nos permite centralizar os esforços ao desenvolvimento da lógica do negócio.

Na minha opinião, o Pex deve ser aplicado a qualquer fluxo de desenvolvimento, seja em projetos, fábricas de codificação, ou qualquer outro ambiente de trabalho.

Acesse o link e conheça mais sobre todo o potencial que o Pex pode oferecer.

Referências

http://research.microsoft.com/en-us/projects/Pex/
http://research.microsoft.com/en-us/projects/pex/pextutorial.pdf

Abraços!