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, você só precisa 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 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 rodando 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 se torna uma mistura, alguns @Test do JUnit 4 e alguns @Test do JUnit 5, e 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 é em relação ao @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ões 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á muitos recursos interessantes no JUnit 5, recomendo que você consulte o Guia do Usuário do JUnit 5, para analisar o que é útil para 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 o seu projeto é grande, 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, o 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 quebrariam 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ê executar alguns testes que usam Jersey, eles não serão carregados, porque existem 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 você de 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 novos testes serão criados com JUnit 5 e o projeto não se tornará um Frankenstein. Então, lembre-se, mantenha 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 tenha um bom design no seu código, isso permite que você mude e se mova com facilidade.