Home Ciência e Tecnologia Biblioteca de asserções para Java: AssertJ versus Google Truth

Biblioteca de asserções para Java: AssertJ versus Google Truth

7
0

fechar notícias

Este artigo também está disponível em inglês. Foi traduzido com assistência técnica e revisado editorialmente antes da publicação.

O teste unitário é um elemento fundamental na engenharia de software. Eles garantem o correto funcionamento do software e ajudam a identificar possíveis erros numa fase inicial. As asserções desempenham um papel importante para garantir que as condições desejadas sejam atendidas durante a execução do teste.

Leia mais depois do anúncio

Marco Dahms trabalha como arquiteto de software há 18 anos. Seu trabalho se concentra em código limpo, integração contínua, computação em nuvem, arquiteturas distribuídas e Kubernetes.

Os testes de unidade contêm afirmações que a estrutura de teste usa para verificar a conformidade durante o teste. Um exemplo simples de verificação de qual é o valor de retorno de um determinado método true é. Se a instrução não se aplicar, o teste aborta sua execução e é considerado falhado. Se todas as instruções forem atendidas, a estrutura de teste abre o teste até o fim e é considerada bem-sucedida.

Um teste unitário pode conter múltiplas instruções, geralmente no final do método de teste. Em casos raros, uma afirmação pode ser verificada no meio de um caso de teste para garantir a conformidade com as condições intermediárias do teste.

A API da estrutura de teste geralmente é usada para formular instruções na linguagem de programação associada. Por exemplo, JUnit for Java oferece uma API simples para expressar asserções.

Geralmente é suficiente para testes simples com poucas instruções e tem a vantagem de estar disponível diretamente no framework de testes. Portanto, não há necessidade de integrar dependências adicionais ao projeto de software.

(Imagem: laolina/123rf.com)

O teste BetterCode() 2026 em 8 de junho de 2026 mostrará como a interação de pessoas, ferramentas e processos garante o sucesso do software moderno. Foco em testes com IA, automação de testes e relatórios práticos que mostram o que testar.

Porém, se o projeto for maior e os testes mais complexos, a API atinge seu limite. Primeiro, eles não são otimizados para leitura e compreensão. Para declarações mais complexas, os desenvolvedores precisam escrever muitos códigos padronizados. Além disso, as mensagens de erro para asserções não conformes são bastante curtas e abstratas e não possuem os detalhes apropriados para solucionar problemas, por exemplo, sobre elementos ausentes em uma coleção. Além disso, a API de asserção do JUnit não é extensível, portanto você não pode estendê-la com asserções para sua própria lógica de domínio.

Leia mais depois do anúncio

A listagem a seguir mostra exemplos que demonstram as limitações da API JUnit Assertion.


  @Test
  public void testListComparison() {
    List expectedList = Arrays.asList("Apple", "Banana", "Cherry");
    List actualList = Arrays.asList("Apple", "Grape", "Cherry");

    assertEquals(expectedList, actualList, "Die Listen sollten gleich sein");
  }


Primeiro, são criadas duas listas contendo strings. Chamada do método assertEquals requer que ambas as listas sejam iguais. Como a lista contém elementos diferentes, o teste falha com a seguinte mensagem:

Die Listen sollten gleich sein ==> expected: <(Apple, Banana, Cherry)> but was: <(Apple, Grape, Cherry)>

A mensagem não especifica quais itens da lista são diferentes. Neste exemplo simplificado, pode ser fácil para os desenvolvedores entenderem, mas na prática, muitas vezes surgem casos mais complexos. Seria útil se a mensagem contivesse informações específicas sobre diferentes elementos. Neste caso: cordas Banana e Grape.

Outra afirmação pode ser que um determinado elemento apareça exatamente uma vez na lista. Este requisito não pode ser implementado diretamente com a API JUnit. Os desenvolvedores devem escrever eles próprios o código necessário. Bibliotecas de asserções como AssertJ ou Google Truth não têm essas limitações. As APIs das duas bibliotecas são otimizadas para legibilidade e compreensão. Suas declarações geralmente parecem linguagem natural. Em particular, múltiplas instruções podem ser encadeadas em uma expressão, reduzindo o código clichê.

As mensagens de erro para declarações violadas são mais detalhadas e mais fáceis de solucionar. Existem também APIs extensas e especializadas para tipos padrão em Java, como strings, listas ou exceções.

AssertJ é uma biblioteca Java de código aberto com muitas asserções e mensagens de erro úteis. O objetivo principal é melhorar a legibilidade do código de teste. AssertJ Core é o núcleo do AssertJ, e existem outros módulos AssertJ para bibliotecas como Jambu.

A biblioteca pode ser usada como org.assertj:assertj-core Integração em projetos Java via Maven e Gradle. Um projeto com Spring Boot gerencia a versão do AssertJ automaticamente. Se necessário, a versão AssertJ pode ser vinculada à propriedade assertj.version substituir.

AssertJ oferece uma variedade de APIs de asserção diferentes para vários tipos Java padrão, incluindo tipos comuns como String, List ou Predicate e tipos primitivos como int ou char. Essa API é específica para cada tipo e fornece uma maneira de evitar a gravação de código clichê. Segue um resumo:

API de string:

  • isNotBlank: String não é uma string vazia
  • contains: String contém substring
  • hasSize: String tem um certo comprimento
  • isUpperCase: String inclui apenas letras maiúsculas

APIs de escuta/iteráveis:

  • contains: A lista contém elementos em qualquer ordem
  • containsOnly: Uma lista contém apenas certos elementos em qualquer ordem
  • containsExactly: Uma lista contém apenas certos elementos em uma determinada ordem

A variedade de declarações abrange muitos casos de uso.

Os desenvolvedores podem adicionar semântica adicional às instruções, fornecendo descrições textuais quando elas são chamadas. Isso faz parte da mensagem de erro se a instrução não for seguida. Uma configuração pode ser usada para controlar se esta descrição deve ser exibida diretamente no console padrão ou consumida usando sua própria lógica no consumidor chamado descrição, por exemplo, para salvar em um arquivo.

O ponto de entrada para desenvolvedores é a classe Assertions e seus métodos assertThat(…). Nomeação assertThat(…) mostra que a ênfase está na intuição e na legibilidade da afirmação. Isso faz com que a declaração pareça uma linguagem natural. O primeiro vai assertThat declarado como importação estática:

import static org.assertj.core.api.Assertions.assertThat;

Em seguida, você pode adicionar um método de teste assertThat(foo). escreva, onde foo refere-se ao valor ou objeto associado à instrução. Depende do que foo para o tipo, o IDE oferece uma API de asserção apropriada se o preenchimento de código estiver configurado corretamente. Por exemplo, você passa um objeto do tipo LocalDate como argumento, você recebe recomendações como hasMonth ou isAfter. Isso faz com que a seguinte instrução seja compilada:

assertThat(date).isNotNull().hasMonth(Month.of(1)).isAfter(beginDate);

A declaração agora pode ser lida em linguagem natural como: “Garantir que a data não seja nula, tenha o mês 1 (janeiro) e que sinceDate caia depois de outra data.” O encadeamento de métodos de chamada evita código clichê e melhora a legibilidade. Assim que uma instrução falhar, a próxima não será verificada novamente.

Quando os desenvolvedores desejam verificar todas as asserções antes de um teste ser abortado, eles usam SoftAssertions. Para fazer isso, eles criam um objeto do tipo SoftAssertionsem seguida, chame o método de instrução desejado e complete-o no final assertAll revisão final. AssertJ então compila um resumo de todas as asserções com falha. Essa abordagem é adequada para casos de teste complexos porque fornece uma visão geral imediata de todos os erros e evita que o teste precise ser reiniciado após cada correção de erro.

Além disso, AssertJ pode ser estendido para incluir asserções para seus próprios domínios de aplicação. Escrever asserções personalizadas permite desenvolver métodos de asserção que se ajustem ao seu próprio modelo de dados. No caso do software de gerenciamento de compromissos, você pode considerar as seguintes afirmações:

  • assertThat(appointment).isDue()
  • assertThat(appointment).isCancelled()

Appointment irá classificar a partir do próprio modelo de domínio e isDue também isCancelled será um método de afirmação autodesenvolvido. Essa abordagem melhora a legibilidade e a compreensão dos testes unitários, refletindo o seu próprio domínio de aplicação a partir do código produtivo nos testes. Para implementar uma instrução personalizada, os desenvolvedores devem criar uma nova classe a partir de uma classe abstrata AbstractAssert retorna construtores e estática assertThatmétodos e métodos de confirmação necessários (por exemplo isDue, isCancelled etc.) implementar.

Outra biblioteca de declarações para Java é o Google Truth, desenvolvida e mantida pela equipe Guava do Google. É usado na maioria de todos os testes na base de código do Google. O foco do conteúdo está em declarações legíveis e mensagens de erro. Truth suporta muitos tipos e tipos Java padrão da biblioteca Jambu. A integração do Truth em projetos Maven ou Gradle é feita através de artefatos com.google.truth:truth.

Para usar Truth em um teste, você deve usar o método assertThatfornecido por meio de importação estática:

import static com.google.common.truth.Truth.assertThat;

Assim como AssertJ, objetos podem ser usados ​​como argumentos assertThat passado, o que resulta em uma instrução de API que corresponde ao tipo do argumento. Um exemplo simples da documentação do Truth é verificar se uma string começa com uma determinada substring:


String string = "awesome";
assertThat(string).startsWith("awe");


Para tornar a mensagem de erro da instrução violada mais semântica, o desenvolvedor pode fornecer uma descrição apropriada. Para fazer isso, importe o método assertWithMessage e ligue:


import static com.google.common.truth.Truth.assertWithMessage;

assertWithMessage("Without me, it's just aweso")
    .that(string)
    .contains("me");


A verdade também permite que você expanda com suas próprias reivindicações. No modelo de dados verdadeiros, você escreve seu próprio assunto personalizado para isso. Sua própria matéria deve ser da turma Subject derrubado. Além disso, requer métodos auxiliares e construtores estáticos. Além disso, devem ser adicionados determinados métodos de confirmação. A documentação do Truth mostra um exemplo de referência EmployeeSubject.

Para testes grandes com muitas afirmações, onde uma verificação completa de todas as afirmações é útil, a turma chega à Verdade Expect para usar, comece por meio da anotação de regra JUnit:

@Rule public final Expect expect = Expect.create();

No objeto Expect você pode então fazer algo semelhante assertThat Passe o argumento e formule a declaração apropriada. Infelizmente, acontece que esta abordagem só é suportada até o JUnit 4. No JUnit 5, a anotação de regras não é mais possível e o Truth ainda não forneceu uma implementação alternativa para ela (em abril de 2026). Como o JUnit 6 foi lançado em setembro de 2025, o uso do JUnit 4 não é recomendado. Conseqüentemente você pode Expect não adianta mais.

Fonte

LEAVE A REPLY

Please enter your comment!
Please enter your name here