Testes parametrizados com JUnit 5

Forneça dependências diretamente no seu método de teste

Quando testamos unitariamente uma classe, por vezes é necessário criar a instância de alguma classe dependente pois o componente a ser testado o exige em alguns fluxos internos, por exemplo em algum método. Os dados contidos naquele objeto precisam ser preparadas a fim de respeitar o contrato de integração. Com JUnit 4, que ainda é muito utilizado, podemos criar em vários pontos, por exemplo antes de cada teste com Before:

@Before
public void initialize() {
    myReference = new MyClass("Jafar", 123);
}

Ou no teste em si:

@Test
public void method() {
    var myReference = new MyClass("Jafar", 123);
    // Assertions and other stuff here
}

Lembrando que poderíamos usar o BeforeClass ou outras estratégia com After, AfterClass e até Rules, embora não seja trivial.

E como ficaria com JUnit 5?

https://junit.org/junit5/

Lógico que teve mudanças, mas para quem faz o uso simples do JUnit, basicamente ficou a mesma coisa. Veja que na documentação que contém a lista de anotações novas os nomes ficaram mais declarativos. Exemplos:

• Before para BeforeEach
• BeforeClass para BeforeAll

E tem agora a anotação ParameterizedTest. Vamos ver um exemplo.

Recebendo parâmetro nos testes

Acredito que o meio mais legal de usar testes parametrizados é com ArgumentsSource. Na documentação ele nem tem tanto destaque assim, mas é o que eu mais vejo vantagem no dia-a-dia.

Para usar esse recurso, é necessário uma dependência específica:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-params</artifactId>
    <version>5.2.0</version>
    <scope>test</scope>
</dependency>

Feito isso, já podemos criar uma implementação de ArgumentsProvider que forneça uma Stream de argumentos de algum tipo.

E então usá-lo em nosso teste. Um ponto importante é que em vez de anotarmos o método de teste com Test, devemos agora usar ParameterizedTest, e não precisamos deixar declarativo o nome do método para relatórios já que podemos usar o DisplayName.

Veja que o assertion não é o built-in do JUnit, já que a própria documentação do JUnit 5 recomenda usar uma biblioteca focada em assertions em vez de usar o seu próprio, então Hamcrest, Truth e o próprio AssertJ, como é o nosso caso, são bem vindos.

Conclusão

Demorou e muito para termos algo melhor que a versão 4 do JUnit, mas finalmente podemos usar algo mais flexível, poderoso e que dê mais liberdade para o desenvolvimento.

Ao som de Paul Simon, The Sound of Silence.