Mauricio Aniche

O código dos testes é tão importante quanto código de produção. E provavelmente você já ouviu aquela famosa frase: “melhor do que escrever código, é apagar código!”. Quando é então que eu apago código de teste?

A primeira e mais óbvia resposta é: quando o teste deixar de fazer sentido! Se a funcionalidade foi removida, você deve atualizar sua bateria de testes e apagar todos os testes relacionados à ela. Bateria de testes desatualizada não serve pra nada! Se a funcionalidade evoluir, você deve evoluir seus testes juntos.

Até aí nada de novidade… Mas vamos lá.

A segunda resposta é: quando você tem testes repetidos! Em algumas situações, quando estamos em dúvida sobre como implementar determinada funcionalidade, optamos por escrever testes parecidos para, de alguma forma, triangularizar até chegar na implementação correta.

Voltando ao velho exemplo da calculadora. Suponha que implementar um algoritmo de soma fosse algo complicado. Você começou com testes simples, como (1+1), depois (1+2), depois (2+2). Nesse momento você encontrou uma maneira de resolver o problema para quaquer (m+n). Seus testes de unidade ficam parecidos com esses:

public class CalculadoraTest {
  @Test
  public void deveSomarUmMaisUm() {
    assertEquals(2, new Calculadora().soma(1,1));
  }

  @Test
  public void deveSomarUmMaisDois() {
    assertEquals(3, new Calculadora().soma(1,2));
  }

  @Test
  public void deveSomarDoisMaisDois() {
    assertEquals(4, new Calculadora().soma(2,2));
  }
}

Esses testes, muito úteis durante o tempo de desenvolvimento do algoritmo, agora se tornaram repetidos. Você, portanto, deve apagá-los! Eles, além de serem inúteis, ainda dificultam o trabalho do desenvolvedor. Se um dia o método testado mudar, você terá que mudar em 10, 20 testes diferentes (mas que testam a mesma coisa!). Lembre-se do acoplamento entre seu código de teste e seu código de produção (sim, ele existe!).

Mas poxa, um testezinho só não é pouco? Não! Você precisa de apenas um teste para garantir a funcionalidade. Não adianta testar a mesma coisa duas vezes.

Você deve ter apenas um teste para cada conjunto de estados válidos e inválidos para uma condição de entrada. A ideia é que todos os elementos de uma classe se comportem de maneira similar. A esses conjuntos damos o nome de classes de equivalência. Escrever apenas um teste por classe de equivalência é uma prática muito comum em testes de caixa preta e é conhecida como particionamento em classes de equivalência. Apesar disso, acredito que ela faça sentido também para testes de caixa branca, como os testes de unidade.

No nosso exemplo da calculadora, poderíamos ter testes para, por exemplo:

• soma de dois números positivos;
• soma de um número positivo com outro negativo;
• soma de um número negativo com outro positivo;
• soma de dois números negativos;
• soma com um dos elementos sendo zero;

public class CalculadoraTest {
  @Test
  public void deveSomarDoisNumerosPositivos() {
    assertEquals(4, new Calculadora().soma(2,2));
  }

  @Test
  public void deveSomarPositivoComNegativo() {
    assertEquals(4, new Calculadora().soma(6,-2));
  }

  @Test
  public void deveSomarNegativoComPositivo() {
    assertEquals(-4, new Calculadora().soma(-6,2));
  }

  @Test
  public void deveSomarDoisNumerosNegativos() {
    assertEquals(-4, new Calculadora().soma(-2,-2));
  }

  @Test
  public void deveSomarComZero() {
    assertEquals(4, new Calculadora().soma(0,4));
    assertEquals(4, new Calculadora().soma(4,0));
  }
}

Obviamente, encontrar todas as classes de equivalência não é um trabalho fácil, e por isso temos a gigante área de testes de software. Mas não é repetindo testes que você garante que seu código funciona.

Referências

Maldonado, Jino, Delamaro. Introdução ao teste de software. Editora Campus, 2007.