A quantidade de asserts em um teste indica algo? (CSMR2013)

Em março, apresentei um pequeno pedaço da minha pesquisa de doutorado no CSMR2013, em Gênova. O CSMR é uma conferência voltada para trabalhos que discutem manutenção e evolução de software.

Meu trabalho discute a relação entre a quantidade de asserts e a qualidade do código de produção. Será que o desenvolvedor faz uso de mais de 1 assert por teste porque o código de produção é complexo? É mais ou menos essa a pergunta que o trabalho visa responder.

No fim, acabei encontrando que a quantidade de asserts unicamente não indica nada: os desenvolvedores usam um número arbitrário de asserts mesmo com o código sendo simples. Mas algo interessante emergiu: se ao invés de contar a quantidade de asserts, eu contar a quantidade de diferentes objetos que recebem uma asserção e fizer a mesma comparação, isso sim indica que o código de produção pode ser mais complicado do que a média.

Em código, pra ficar mais fácil de entender:

assertEquals(“esperado”, a.getAlgumaCoisa());
assertEquals(“esperado2”, a.getAlgumaOutraCoisa());

Veja que estou fazendo 2 asserts, mas sempre no mesmo objeto “a”. Agora:

assertEquals(“esperado”, a.getAlgumaCoisa());
assertEquals(“esperado2”, b.getAlgumaOutraCoisa());

Veja que tenho 2 asserts em 2 objetos diferentes: “a” e “b”. Nesse caso, os métodos “getAlgumaCoisa()” e “getAlgumaOutraCoisa()” podem estar mais complicados do que deveriam. Portanto, acabei propondo o mau cheiro de teste que é “Mais de Uma Instância de Objeto Recebendo Asserção”. Repare nesse padrão, pois ele pode indicar problemas no seu código de produção.

Você pode ler o paper completo aqui se preferir! 🙂

2 thoughts on “A quantidade de asserts em um teste indica algo? (CSMR2013)

  1. Bruno

    Mauricio, acho muito legal que você esteja fazendo esse trabalho relacionado a testes unitários na área acadêmica. Dei uma olhada rápida no paper para ver os projetos estudados, acho que seria interessante colocar na lista projetos como Sonar, o próprio JUnit e alguns populares do Spring e JBoss. Claro que somente se passarem pelo critério de seleção.

    Uma outra ideia, que talvez não seja adequada para o estudo do paper, seria para tentar validar as métricas utilizadas (LoC, CC, NoMI) comparando projetos considerados bons pela comunidade com os considerados ruins. Eu sei que é um pouco subjetivo ‘bom’ e ‘ruim’ mas vale a pena investigar um pouco..A

    Reply
    1. mauricioaniche Post author

      Oi Bruno,
      Obrigado pelo feedback. Faz sentido sim. Nesse momento, estou trabalhando exatamente nesse filtro. Como pegar projetos bons, bem testados, e etc. Chego lá e mantenho vc atualizado por aqui! 🙂

      Um abraço,
      Mauricio

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *