Novidades e o futuro do JUnit by Marc Philipp

Olá, pessoal!

Hoje vamos mergulhar nas novidades e no futuro do JUnit, o framework de testes mais popular do Java. Vamos fazer um resumo de uma sessão com Marc Philipp, o team lead da equipe JUnit, que está agora trabalhando em tempo integral no projeto, graças ao financiamento do Sovereign Tech Fund. Preparem-se para um resumo didático sobre o que há de novo e o que está por vir!

O JUnit em um Relance: Um Legado de Testes

O JUnit é um dos projetos open source Java mais antigos, criado por Kent Beck e Erich Gamma em 1997. É um projeto independente, sem o apoio de uma única empresa, e grande parte do trabalho é feita no tempo livre dos colaboradores, embora Marc esteja em tempo integral atualmente.

Existem algumas gerações do JUnit:

• JUnit 4.x: Ainda muito utilizado, com baseline no Java 5 e agora em modo de manutenção, recebendo apenas correções críticas e de segurança.

• JUnit 5.x: Lançado em 2017, com baseline no Java 8 e suporte a recursos modernos do Java. É o foco principal das discussões atuais.

• JUnit 6.0: A próxima geração, que promete simplificar a migração e trazer novos requisitos, como o Java 17.

  Marc Philipp, que é um committer desde 2012 e team lead desde 2016, tem trabalhado em várias melhorias importantes.

As Mais Recentes Melhorias no JUnit 5.13

As versões mais recentes do JUnit 5.x, especialmente a 5.13, trouxeram recursos muito aguardados:

1. Relatórios de Teste Aprimorados

O JUnit agora oferece relatórios de teste muito mais legíveis e ricos, um avanço significativo em relação aos formatos legados.

• Open Test Reporting XML Format: Introduzido na versão 5.9, este novo formato XML é pensado para substituir o antigo, que não suportava recursos modernos do JUnit Platform, como tags, estruturas hierárquicas e testes aninhados. Ele funciona de forma baseada em eventos (início e fim de cada nó da árvore de testes) e também em um formato hierárquico, que é um pouco mais legível por humanos, embora ainda seja XML.

• Relatório HTML: A grande novidade é a capacidade de gerar um relatório HTML completo a partir dos arquivos XML. Isso torna a análise dos resultados dos testes muito mais amigável.

  • Como Funciona: Você precisa adicionar a dependência junit-platform-reporting e ativar a geração do formato XML via configuração. Em seguida, uma ferramenta CLI do projeto Open Test Reporting converte esses arquivos XML em um relatório HTML.

  • Recursos do Relatório HTML:

    • Visão Geral Clara: Barra de status (verde para sucesso, vermelho para falha), informações sobre o ambiente de execução (OS, JVM) e até mesmo o status do repositório Git no momento da execução.

    • Árvore de Testes: Uma representação hierárquica clara dos seus testes, similar ao que você vê na IDE.

    • Detalhes de Falha: Em caso de falha, você obtém a stack trace completa, com a opção de copiá-la facilmente para sua IDE.

    • Entradas de Relatório: Possibilidade de publicar dados arbitrários (como string-string maps) ou anexar arquivos (textos são mostrados inline, imagens são incorporadas) diretamente no relatório, o que é útil para testes de UI, por exemplo.

    • Modo Escuro: Sim, porque todo mundo gosta!

  • Integração com CI: Embora não haja uma integração direta com a UI do GitHub Actions para HTML completo, é possível arquivar o relatório HTML como um artefato. O arquivo HTML é self-contained, facilitando o compartilhamento.

  • Formato Agnóstico: O esquema XML subjacente é agnóstico à plataforma, o que significa que outras frameworks de teste (como PHPUnit) já estão começando a adotar esse formato.

2. Classes de Teste Parametrizadas

Esta é uma funcionalidade altamente solicitada, que permite parametrizar uma classe inteira de testes, em vez de apenas métodos individuais.

• Motivação: Evitar a duplicação de código quando múltiplos métodos de teste precisam ser executados com o mesmo conjunto de parâmetros. Imagine testar diferentes implementações de uma interface (como List) com o mesmo conjunto de testes.

• Como Usar:

  • Anote sua classe com @ParameterizedClass.

  • Use anotações de origem (SourceAnnotation) no nível da classe (como @MethodSource ou @ValueSource) para fornecer os argumentos.

  • Os parâmetros podem ser injetados via injeção de campo (anotando o campo com @Parameter) ou injeção de construtor (ideal para classes record ou com construtores personalizados).

  • Cuidado com Dados Mutáveis: Se os dados ou instâncias injetadas forem mutáveis, a ordem de execução dos testes pode importar, levando a flaky tests. O ideal é usar dados imutáveis ou implementar métodos @AfterEach para resetar o estado.

  • Conversores Customizados: Você pode usar @ConvertWith para converter strings ou outros tipos para seus objetos, especialmente útil com @ValueSource.

  • Métodos de Ciclo de Vida Específicos: Há suporte para métodos static @BeforeParameterizedClassInvocation para inicializações complexas.

• Combinando Recursos: É possível combinar classes parametrizadas com testes aninhados e até mesmo métodos de teste parametrizados, embora isso possa levar a uma "explosão" de combinações de testes.

3. Relato de Problemas de Descoberta de Testes

Um pesadelo para qualquer desenvolvedor é escrever um teste e ele não ser executado. Antes da versão 5.13, o JUnit silenciosamente ignorava testes malformados. Agora, ele protege você contra isso!

• O Problema: Métodos anotados com @Test que não são válidos (por exemplo, retornam um int em vez de void ou Unit no Kotlin, classes aninhadas estáticas) eram descartados sem aviso.

• A Solução: O JUnit Platform agora coleta e relata esses problemas.

  • Warnings e Erros Críticos: Problemas não críticos são logados como warnings. Problemas críticos podem fazer a execução do teste falhar.

  • Severidade Configurável: A severidade padrão para falha é "error", mas você pode configurá-la para "warning" ou "info", garantindo que qualquer problema leve à falha da build, semelhante ao tratamento de warnings como erros em compiladores.

  • Exemplos: Retorno de tipo incorreto em @Test ou @TestFactory, classes aninhadas declaradas como static.

• Assistência da IDE: IDEs como o IntelliJ IDEA já oferecem inspeções para muitos desses problemas, mas nem sempre os desenvolvedores prestam atenção aos avisos visuais. A falha da build torna isso impossível de ignorar.

O Roteiro para o JUnit 6.0

A próxima grande versão do JUnit, a 6.0, trará algumas mudanças importantes:

• Migração Simplificada: A boa notícia é que não será uma migeração drástica como a do JUnit 4 para o 5. A API do JUnit Jupiter permanecerá amplamente a mesma.

• Requisitos de Versão:

  • Java 17: Será o baseline mínimo necessário.

  • Kotlin 2.2: Também será um requisito.

• Novidades:

  • JSpecify: Informações de anulabilidade (nullability) estarão disponíveis em todas as APIs.

  • Remoção de APIs Deprecadas: APIs que estavam deprecadas desde o 5.10 (há cerca de 3 anos) serão removidas, incluindo o JUnitPlatformRunner (um adaptador para rodar testes JUnit 5 em ambientes JUnit 4).

  • Depreciação de Camadas de Compatibilidade: O JUnit Vintage Engine (necessário para rodar testes JUnit 3 e 4 na plataforma JUnit 5) será deprecado, mas não para remoção imediata, sendo uma solução temporária para migrações.

• Suporte de Longo Prazo para 5.13: Para aqueles que não podem migrar para Java 17 imediatamente, o JUnit oferecerá suporte de longo prazo (LTS) para a versão 5.13, com correções de bugs e segurança, mas sem novos recursos.

Conclusão

O JUnit continua evoluindo, trazendo ferramentas cada vez mais robustas e amigáveis para garantir a qualidade do seu código. Os novos relatórios HTML, as classes de teste parametrizadas e a detecção proativa de problemas de descoberta de testes são adições fantásticas que certamente farão a diferença no dia a dia dos desenvolvedores.

Experimente os novos recursos, especialmente os relatórios HTML e as classes parametrizadas, e não deixe de dar seu feedback no repositório do GitHub. É assim que o projeto continua a melhorar! E fique de olho no JUnit 6.0, que promete ser uma atualização mais tranquila e poderosa.

Até a próxima!

Referências