JUnit, 4, 5, Jupiter, Vintage

Após o lançamento do JUnit 5, muitos desenvolvedores simplesmente adicionaram essa incrível nova biblioteca aos seus projetos, pois diferente das outras versões, nesta nova versão, não é necessário migrar do JUnit 4 para o 5, basta incluir a nova biblioteca no seu projeto, e com todo o motor do JUnit 5 você pode fazer seus novos testes usando JUnit 5, e os mais antigos com JUnit 4 ou 3, continuarão funcionando sem problemas.

Porém, o que pode acontecer em um grande projeto, um projeto que foi construído há 10 anos com duas versões do JUnit funcionando em paralelo?

Novos desenvolvedores começaram a trabalhar no projeto, alguns deles com experiência em JUnit, outros não. Novos testes são criados usando JUnit 5, novos testes são criados usando JUnit 4, e em algum ponto um desenvolvedor sem conhecimento, ao criar um novo cenário em um teste JUnit 5 que já foi criado, simplesmente inclui uma anotação JUnit 4, e o teste vira uma mistura, alguns @Test do JUnit 4 e alguns @Test do JUnit 5, e a cada dia fica mais difícil remover a biblioteca JUnit 4.

Então, como resolver esse problema? Primeiro de tudo, você precisa mostrar para sua equipe o que é do JUnit 5 e o que é do JUnit 4, para que novos testes sejam criados usando JUnit 5 em vez de JUnit 4. Depois, é necessário seguir a regra do Escoteiro, sempre que passarem por um teste JUnit 4, devem migrar para JUnit 5.

Vamos ver as principais mudanças lançadas no JUnit 5. Tudo começa pelo nome, no JUnit 5, você não vê pacotes chamados org.junit5, mas sim org.junit.jupiter. Resumindo, tudo o que você vê com “Jupiter” significa que é do JUnit 5. Eles escolheram esse nome porque Júpiter começa com “JU” e é o quinto planeta a partir do sol.

Outra mudança é sobre o @Test, essa anotação foi movida para um novo pacote: org.junit.jupiter.api e agora não se usa mais atributos como “expected” ou “timeout”, usa-se extensão em vez disso. Por exemplo, para timeout, agora você tem uma anotação para isso: @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Outra mudança é que nem métodos de teste nem classes precisam ser públicos.

Agora, em vez de usar @Before e @After na configuração do seu teste, você tem que usar @BeforeEach e @AfterEach, e também tem @BeforeAll e @AfterAll. 

Para ignorar testes, agora você tem que usar @Disable em vez de @Ignore. 

A great news that was released in JUnit 5 was the annotation @ParameterizedTest, with that is possible to run one test multiple times with different arguments. For example, if you want to test a method that creates some object and you want to validate if the fields are filled correctly, you just do the following:

@ParameterizedTest
@MethodSource("getInvalidSources")
void shouldCheckInvalidFields(String name, String job, String expectedMessage) {
	Throwable exception = catchThrowable(() -> new Client(name, job));
  
  	assertThat(exception).isInstanceOf(IllegalArgumentException.class)
      .hasMessageContaining(expectedMessage);
}

static Stream<Arguments> getInvalidSources() {
	return Stream.of(Arguments.arguments("Jean Donato", "", "Job is empty"),
                     Arguments.arguments("", "Dev", "Name is empty"));
}

Há muitas funcionalidades legais no JUnit 5, recomendo que você consulte o Guia do Usuário do JUnit 5, para analisar o que é útil para o seu projeto.

Agora que todos os desenvolvedores sabem o que foi alterado no JUnit 5, você pode iniciar o processo de remoção do JUnit 4 do seu projeto. Então, se você ainda está usando JUnit 4 em 2024, e seu projeto é grande, você provavelmente terá algumas dependências usando JUnit 4. Recomendo que você analise suas bibliotecas para verificar se algumas delas estão usando JUnit 4.

Na imagem abaixo, estou usando o Dependency Analyzer do IntelliJ.

Como você pode ver, jersey-test está usando JUnit 4, ou seja, mesmo que eu remova JUnit 4 do meu projeto, JUnit 4 estará disponível para uso porque o Jersey. A maneira mais fácil será atualizar o jersey para a versão 2.35, pois o JUnit 5 foi introduzido no jersey-test 2.35, mas não posso atualizar o jersey-test framework porque outras bibliotecas quebrarão no meu projeto. Então, neste caso, o que posso fazer?

I can exclude JUnit from Jersey with Dependency Exclusions from Maven (like the image below). That way JUnit 4 will not be used anymore, but rather our JUnit 5. 

Quando você executa alguns testes que usam Jersey, eles não serão carregados, porque há métodos no Jersey usando anotações do JUnit 4, setUp e tearDown, usando @Before e @After. Para resolver isso, você pode criar uma “Classe de Configuração” que extends JerseyTest implementando setUp e tearDown com @BeforeEach e @AfterEach chamando super.setUp() e super.TearDown().

public class JerseyConfigToJUnit5 extends JerseyTest {

  @BeforeEach
  public void setUp() throws Exception {
  	super.setUp();
  }
  
  @AfterEach
  public void tearDown() throws Exception {
  	super.tearDown();
  }
}

Então, se você já verificou suas bibliotecas e ninguém depende mais do JUnit 4, finalmente pode migrar todos os seus testes para o JUnit 5. Para esse processo, há uma boa ferramenta que poupa muito trabalho, é o OpenRewrite, um ecossistema de refatoração automática para código-fonte, eles vão mudar todos os seus pacotes antigos, as antigas anotações e tudo para o novo.

É isso aí pessoal, agora você e seus colegas podem aproveitar o JUnit 5 e relaxar a mente sabendo que os novos testes serão criados com JUnit 5 e o projeto não se transformará em um Frankenstein. Então, lembrem-se, mantenham seu projeto atualizado, porque se você esquecer suas bibliotecas, cada dia será mais difícil atualizar, sempre use especificações e frameworks que seguem as especificações e tenham um bom design no seu código, isso permite que você mude e se mova com facilidade.