Rafael Naufal's blog

Há uns tempos atrás comecei a testar o projeto Hamcrest junto com o framework JUnit para criar testes unitários mais legíveis.

O projeto Hamcrest foi criado para melhorar a legibilidade do código de testes. É um framework que facilita a criação de objetos do tipo matcher que combinam regras presentes em testes de unidade. Seguem alguns examplos para deixar a idéia mais clara:

   1 import static org.hamcrest.CoreMatchers.equalTo;
   2 import static org.hamcrest.CoreMatchers.is;
   3 import static org.junit.Assert.assertThat;
   4 
   5 @Test
   6 public void shouldBeTheSamePerson()
   7 {
   8     Person me = new Person( "Rafael" );
   9     Person theOther = new Person( "Rafael" );
  10     assertThat( me, is( theOther ) );
  11 }
  12 
  13 @Test
  14 public void shouldHaveFixedSizeNumbers()
  15 {
  16     List<Integer> numbers = Arrays.asList( 1, 2, 3, 4, 5 );
  17     assertThat( numbers.size(), is( equalTo( 5 ) ) );
  18 }

O primeiro exemplo checa se um objeto do tipo Person é igual a outro usando o método equals, que foi sobrescrito na classe Person. A sintaxe is define um matcher que é um sinônimo para is(equalTo(valor)). O segundo exemplo utiliza o matcher is(equalTo(valor)) para checar o tamanho de uma lista de inteiros de tamanho fixo. O método assertThat é usado em conjunto com o matcher is(equalTo(valor)), que faz com que as sentenças de teste se tornem mais legíveis.

Algo interessante é a possibilidade de customizar a API de matcher, extendendo-os, como este exemplo que testa se uma dada lista contém somente números pares:

   1 public class AreEvenNumbers extends TypeSafeMatcher<Collection<Integer>> {
   2 
   3     @Override
   4     public boolean matchesSafely(Collection<Integer> numbers) {
   5         for (Integer number : numbers) {
   6             if (number % 2 != 0) {
   7                 return false;
   8             }
   9         }
  10         return true;
  11     }
  12 
  13     @Override
  14     public void describeTo(Description description) {
  15         description.appendText("even numbers");
  16     }
  17 
  18     @Factory
  19     public static <T> Matcher<Collection<Integer>> evenNumbers() {
  20         return new AreEvenNumbers();
  21     }
  22 }

E abaixo temos dois testes que utilizam o novo matcher AreEvenNumbers:

   1 import static org.hamcrest.CoreMatchers.is;
   2 import static org.junit.Assert.assertThat;
   3 import static br.com.rafael.hamcrest.AreEvenNumbers.evenNumbers;
   4 
   5 @Test
   6 public void shouldHaveOnlyEvenNumbers()
   7 {
   8     List<Integer> numbers = Arrays.asList( 2, 4, 6, 8, 10 );
   9     assertThat( numbers, is( evenNumbers() ) );
  10 }
  11 
  12 @Test
  13 public void shouldNotHaveOddNumbers()
  14 {
  15     List<Integer> numbers = Arrays.asList( 1, 2, 4, 6, 8, 10 );
  16     assertThat( numbers, not( evenNumbers() ) );
  17 }

Estes dois testes utilizam o método estático evenNumbers que fabrica os matchers no código de teste. Note o uso do matcher not no teste shouldNotHaveOddNumbers para garantir que números ímpares não estão presentes na lista. Todos os testes usam a funcionalidade de import estático, que torna o teste mais limpo e claro sem o nome da classe para invocar o método.

Ainda não tive a oportunidade de testar os matchers Beans, Collections e Number nos testes unitários. Eu acho que eles deixam os testes mais claros e mais fáceis de mudar. E você? Já utilizou o projeto Hamcrest? Se você tem mais exemplos, poste-os aqui!

Tags: google, hamcrest, java, junit, matchers, testes