Competição de Teste de Unidade

Meus empregadores realizam uma competição mensal de testes unitários. Um dia inteiro é dedicado a escrever testes de unidade - obviamente, fazemos mais testes ao longo do mês, mas este é um dia inteiro - e o "vencedor" da competição recebe um prêmio. No entanto, estamos descobrindo que é difícil determinar quem é o vencedor.

Estávamos atribuindo pontos para cada caso de teste. Então, se você escreveu um teste de unidade como este ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

você receberia 100 pontos. Obviamente, este é um exemplo simplista, mas demonstra os problemas ao atribuir "pontos" a cada caso de teste.

Somos principalmente uma loja Java e Javascript. Então, sugeri contar o número de ramificações de código testadas como uma métrica. Podemos contar facilmente as ramificações testadas por meio de uma ferramenta de cobertura de código (como EclEmma). No entanto, não tenho certeza de como faríamos isso com nossos testes Selenium e obter uma cobertura de código nas fontes Javascript (alguma idéia?)

Alguém tem alguma sugestão sobre como podemos determinar melhor o vencedor desta competição?

Editar

Sei como escrever testes de unidade, sei como escrever testes de unidade eficazes, não preciso de ajuda para determinar o que testar. Não tenho controle sobre essa competição - a competição continuará. Então, ou adiciono alguma informação para melhorar ou continuo jogando os testes (sim, eu jogo com eles. É claro que eu jogo com eles. Há prêmios a serem ganhos)

Editar

Essa pergunta aqui obviamente não é duplicada, embora contenha informações úteis sobre como encontrar bons casos de teste, ela não fornece métricas úteis para avaliar a concorrência.

Alguém tem alguma sugestão sobre como podemos determinar melhor o vencedor desta competição?

A única coisa que faz sentido para mim é votar - todo desenvolvedor pode atribuir alguns pontos ao teste de qualquer outro desenvolvedor (exceto o seu). Talvez 3 pontos para o teste ele ache que é o "mais eficaz", 2 pontos para o segundo e um para o terceiro. O teste com mais pontos vence. Pode dar melhores resultados quando a atribuição de pontos é feita sem saber de antemão quem escreveu o teste específico.

Como bônus, você receberá todos os seus testes revisados ​​por pares.

Então, se você escreveu um teste de unidade como este ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

você receberia 100 pontos.

Eu daria a essa pessoa 0 pontos (mesmo que o teste estivesse testando algo realmente relevante), porque afirmações dentro de um loop fazem pouco sentido e testes com várias afirmações (especialmente na forma de um loop ou mapa) são difíceis de trabalhar.

O problema é essencialmente ter uma métrica que não pode [facilmente] ser enganada. Uma métrica baseada exclusivamente no número de afirmações é exatamente o mesmo que pagar aos desenvolvedores por LOC gravado. Tal como acontece com o pagamento por LOC, que leva a códigos enormes e impossíveis de manter, a política real da empresa leva a testes inúteis e possivelmente mal escritos.

Se o número de afirmações é irrelevante, o número de testes também é irrelevante. Esse também é o caso de muitas métricas (incluindo as combinadas) que se poderia imaginar para esse tipo de situação.

Idealmente, você aplicaria uma abordagem sistêmica. Na prática, isso quase não funciona na maioria das empresas de desenvolvimento de software. Então, eu posso sugerir algumas outras coisas:

1. Usando revisões de pares para testes e ter algo semelhante ao número de WTFs por minuto métrica.

2. Meça o impacto desses testes ao longo do tempo no número de bugs . Isso tem vários benefícios:

   • Parece justo,
   • Na verdade, pode ser medido se você coletar dados suficientes sobre relatórios de bugs e seu destino,
   • Realmente vale a pena!

3. Use a cobertura da filial , mas combine-a com outras métricas (além de uma revisão). A cobertura das agências tem seus benefícios, mas testar o código CRUD apenas para obter uma nota melhor não é a melhor maneira de gastar o tempo dos desenvolvedores.

4. Decida todos juntos quais são as métricas que você deseja aplicar no momento (essas decisões podem não ser bem-vindas ou até mesmo possíveis em algumas empresas e equipes). Revise e altere as métricas com frequência, escolhendo aquelas que se tornam mais relevantes e verifique se todos entendem claramente o que é medido e como.

Suponho que seu empregador organize esse dia de testes unitários para incentivar as pessoas a encontrar bugs, obter maior cobertura de código e também acabar tendo mais testes, que serão úteis para sempre.

Então, eu acho que faria sentido que o vencedor fosse o desenvolvedor que encontrar mais erros, ou o desenvolvedor cujos testes obtiverem o maior aumento na cobertura do código.

Um teste lhe dará um ponto se fizer com que uma nova entrada seja aberta no seu sistema de rastreamento de problemas / bugs / defeitos. Se uma entrada já estiver aberta para esse problema, ela não conta. Além disso, conforme sugerido nos comentários, erros no seu próprio código não contam; apenas erros no código de outras pessoas devem contar. Infelizmente, essa abordagem não oferece gratificação instantânea, pois pode levar alguns dias até que todos os testes com falha sejam analisados ​​e os problemas correspondentes sejam abertos. Além disso, isso nem sempre funciona; À medida que o sistema amadurece, pode começar a se tornar extremamente raro descobrir erros adicionando testes.

O aumento na cobertura do código pode fornecer uma medida mais objetiva da melhoria representada pelos novos testes. Primeiro, a cobertura total do código deverá ser registrada no dia anterior à competição. Em seguida, cada desenvolvedor precisará mostrar, de alguma forma, o aumento na cobertura de código resultante apenas de seus testes, sem levar em conta o aumento na cobertura de código resultante de testes escritos por outros desenvolvedores. Isso significa que você provavelmente precisará de um árbitro que irá à máquina de cada desenvolvedor e registrará a nova cobertura de código antes que os testes sejam realizados.

Aliás, levar em consideração a cobertura do código oferece uma recompensa justa para as pessoas que escrevem testes reais, em vez de fazer coisas tolas como o exemplo que você forneceu na pergunta.