Automatizando a criação de testes de unidade

Quais são algumas estratégias que podem ser usadas para automatizar a criação de casos de teste de unidade? Quais aspectos você precisaria considerar em cada classe para poder gerar pelo menos um esqueleto decente de caso de teste?

Sei que uma solução automática abrangente não é prática, mas gostaria de acelerar um pouco a criação do teste, criando um esqueleto. Não estou procurando exemplos de código, apenas talvez algumas sugestões de onde começar ou exemplos de onde algo como isso foi feito, para que eu possa ver como eles o abordaram e o que pode ser possível.

Estou particularmente interessado em métodos para criar esqueletos de teste de unidade em PHP, que não fornecem todas as ferramentas que outras linguagens oferecem, como dicas de tipo completo , por exemplo.

Sua estratégia e seu esqueleto dependem, de maneira não trivial, de quais tipos de testes você deseja gerar, que tipo de cobertura você procura e o idioma / ambiente em que está trabalhando.

É bastante simples escrever um gerador de teste que, para linguagens como C ou Java, leia assinaturas de classe e gere automaticamente testes para casos de canto padrão (passando 0, 2 valores aleatórios, MAX_INT, MIN_INT, para um argumento inteiro, nulos para nulos) , etc ...). Em seguida, você pode executar os testes gerados, registrar os resultados de cada teste e filtrá-los manualmente para remover os irrelevantes, aprovar resultados aceitáveis ​​para testes aprovados (para que eles possam passar automaticamente a partir de então) e marcar como inválidos que falharem. .

Você pode aumentar isso marcando / comentando / refatorando classes para ajudar seu gerador com dicas extras. Você pode ter uma tag que lista todas as exceções possíveis que uma chamada de método pode gerar, ou que fornece um intervalo reduzido de números inteiros válidos para um argumento inteiro. Veja isso como uma abreviação para ter que escrever os testes você mesmo.

Então, aqui estão alguns componentes que você deseja examinar:

• Um componente para analisar automaticamente o código fonte / assinaturas de função / anotações manuais, produzindo casos de teste padrão ou contornos / assinaturas para casos de teste que aguardam a conclusão da entrada.
• Um idioma de tags / anotações / comentários em constante crescimento / alteração, que pode atingir qualquer nível de granularidade (método / classe / assinatura / loops while / etc ...) representando dicas para o construtor de testes automatizado. Idealmente, você deve poder brincar com esse idioma sem precisar recodificar sua estrutura ou qualquer parte dela
• Executor de teste automatizado, com a capacidade de identificar testes novos / antigos e registrar / testar com respostas "aceitáveis" para cada teste. Idealmente, esse corredor criará um banco de dados de execuções de teste, resultados aceitos / recusados ​​e resultados aceitáveis ​​atuais para cada teste.
• "Objeto falsificado" automatizado que, dado um nome de classe e um mapa de nomes-> valores, pode gerar um objeto que imita a classe, retornando dados personalizáveis ​​para chamadas de função, acessadores, slots de dados públicos, etc.

Existem muitas estruturas de teste por aí, que já incluem partes dessa funcionalidade para vários idiomas e plataformas. Embora seja bastante fácil começar a fazer esse trabalho você mesmo e desenvolver esse tipo de estrutura organicamente internamente, também é um projeto interminável de longo prazo que provavelmente duplicará o trabalho existente. Eu recomendo reservar um tempo significativo para analisar o que está disponível primeiro e depois decidir se vale a pena mergulhar.

Ainda não tive chance de usá-lo em um aplicativo de tamanho ou complexidade significativo, mas existem ferramentas, incluindo o CodePro AnalytiX do Google , que automatizam a geração de testes de unidade para aplicativos Java . Também encontrei um produto comercial, o Teste C ++ da Parasoft , que parece permitir a geração de testes de unidade C ++

Esses aplicativos usavam heurísticas para gerar casos de teste. Não tenho certeza de que exista uma estrutura única que você possa usar para produzir um esqueleto, mas há construções que você pode procurar. Costumo me concentrar em loops, instruções condicionais ( ifblocos, switch/ casedeclarações) e exceções, além de criar casos de teste que forçam a execução de diferentes caminhos de execução.

Eu não focaria em acelerar a escrita de testes tentando criar um esqueleto ou modelo, mas melhorando a análise da especificação e / ou implementação e escrevendo testes de alta qualidade. Ser capaz de identificar quais testes agregam mais valor cedo, escrevendo-os e preenchendo os furos mais tarde teria um impacto maior na produtividade e na qualidade.

Apenas para oferecer um pouco mais de publicidade, Falcon experimentou o CodePro em um projeto e escreveu um pouco sobre suas experiências .

Eu escrevi um gerador para acelerar o teste de unidade de um projeto .NET há alguns anos. Havia uma grande base de código sem testes de unidade e tinha como objetivo aumentar rapidamente a cobertura básica. Aqui estão algumas notas que podem ser úteis:

• Minha chance foi que a estrutura principal sobre a qual o projeto foi desenvolvido fornecesse operações padrão e nomeação de classes. Se você está pensando em escrever sua própria, uma estrutura padrão como essa ajudará bastante.
• O uso data-driven testingajuda muito, se a sua base de código permitir. A estrutura de teste criou uma tabela de banco de dados para cada teste de unidade para armazenar dados de teste, de modo que cada linha naquela tabela fosse um teste separado e nenhum código adicional fosse necessário ( Regra de Representação ). A partir deste momento, os testes reais podem ser facilmente criados automaticamente ou inseridos manualmente.
• Os testes unitários resultantes foram simples, mas serviram como smoke tests pelo menos. Para áreas de maior risco, testes manuais adicionais foram escritos.

Para resumir, concordo que uma solução genérica seria impraticável (se possível). Acredito que as chances são melhores se a base de código for adequada para geração de teste e a estrutura de teste puder tirar proveito de sua estrutura.

(Como uma nota lateral, há Pex , mas é para .NET)