Teste unitário com JUnit

JUnit � uma API de c�digo aberto para a cria��o de testes unit�rios em Java, bem como outras linguagem compat�veis com a JVM. Um dos seus principais projetistas, o cientista Erich Gamma, conhecido pelo livro Design Patterns: Elements of Reusable Object-Oriented Software, citou como a motiva��o por tr�s do JUnit permitir a cria��o de testes que s�o f�ceis de escrever e executar. Aqui falamos sobre como come�ar nesta ferramenta.

Vis�o geral

Escrever testes � a forma mais b�sica de garantir a qualidade do c�digo. Ainda nos primeiros passos na programa��o costuma-se introduzir no c�digo pequenos trechos de teste para verificar se o programa se comporta como esperado, em um dado momento da sua execu��o, mesmo sem usar nenhuma t�cnica para isso. Um exemplo � quando criamos uma classe com um m�todo main() em um lugar qualquer do projeto, apenas para verificar se alguma funcionalidade do sistema est� correta.

public static void main(String[] args) {
    ProdutoRepositorio repositorio = new ProdutoRepositorio();
    Produto produto = new Produto("Aparelho de barbear", 39.9, ...);
    repositorio.salvar(produto);
}

A medida que ganhamos experi�ncia, principalmente quando come�amos a lidar com sistemas maiores, � natural sentir falta de uma metodologia de testes que permita medir a cobertura do c�digo testado, tornando f�cil criar os cen�rios nos quais as falhas ser�o percebidas. Os testes unit�rios suprem essas e outras car�ncias no processo de teste de c�digo.

Supondo que com o c�digo anterior desejamos validar se um produto que � cadastrado duas vezes com o mesmo nome faz o programa falhar, poder�amos escrever o seguinte teste para comprovar o lan�amento de uma exce��o.

@Test
public void testaAGravacaoDeUmProdutoJaCadastrado() {
    ProdutoRepositorio repositorio = new ProdutoRepositorio();
    Produto produto = new Produto("Aparelho de barbear", 39.9, ...);
    
    assertThrows(repositorio.salvar(produto), ProdutoComNomeJaCadastradoException.class) ;
}

Geralmente, escrevemos testes unit�rios com o aux�lio de alguma API, que fornece as anota��es e m�todos que precisamos para isso. O programador Java conta com uma das primeiras criadas para esse fim e que influenciou o surgimento de muitas outras, o JUnit. Com ele, a partir de anota��es e algumas declara��es, conseguimos avaliar classes e m�todos para saber se eles apresentam o comportamento desejado. Com o JUnit, tamb�m evitamos aquela pr�tica t�o comum de criar um m�todo main() em qualquer lugar do projeto, apenas para saber se um certo trecho c�digo est� correto.

Instala��o

O primeiro pr�-requisito para executar testes com o JUnit � ter em seu ambiente de desenvolvimento o Java vers�o 8 ou superior. Quanto a instala��o, as duas principais ferramentas de gerenciamento de depend�ncias em projetos Java atualmente s�o o Maven, predominante em projetos para a web, e o Gradle, padr�o no Android. Aqui falaremos sobre como instalar o JUnit 5 em ambos os gerenciadores de depend�ncia.

maven

Uma das formas mais f�ceis de instalar o JUnit � atrav�s do seu reposit�rio no maven. Para isso, em seu projeto localize o arquivo pom.xml, que � criado pela IDE no diret�rio raiz na maioria dos casos, e adicione nele as seguintes depend�ncias:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-api</artifactId>
        <version>5.3.0</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-params</artifactId>
        <version>5.3.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Note que usamos acima o escopo de teste na declara��o da depend�ncia. Isso indica que os pacotes junit-jupiter-api e junit-jupiter-params ser�o necess�rios apenas durante as etapas de compila��o e execu��o dos testes.

gradle

Caso voc� esteja utilizando o Gradle e o JUnit ainda n�o esteja dispon�vel em seu ambiente de desenvolvimento, sua instala��o pode ser feita da seguinte forma:

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.3.0'
    testImplementation 'org.junit.jupiter:junit-jupiter-params:5.3.0'
}

test {
    useJUnitPlatform()
}

Embora o JUnit possa ser instalado manualmente em um projeto Android, na maioria das vezes isso n�o � necess�rio, pois o Android Studio j� adiciona o suporte aos testes unit�rios no projeto.

Configura��o

Para executar os testes com o JUnit precisamos de um motor de execu��o, que pode ser obtido pelo JAR junit-jupiter-engine, a qual tamb�m est� dispon�vel no reposit�rio central do maven. A partir da sua vers�o 2016.2, o Intellij IDEA passou a integrar suporte a execu��o de testes dessa maneira, trazendo para o projeto os JARs necess�rios para isso. Contudo, apenas em vers�es posteriores isso passou a feito baseado na vers�o do JUnit utilizado pelo projeto, aquela informada no pom.xml. Portanto, caso voc� esteja trabalhando em uma vers�o da API diferente daquela hospedada pela IDE erros estranhos podem ser percebidos durante a execu��o dos testes.

Uma forma de evitar essa situa��o � adicionando manualmente os JARs que devem estar dispon�veis em tempo de execu��o, sendo eles o junit-platform-launcher, junit-jupiter-engine e junit-vintage-engine. Em caso de problemas, veja abaixo como fazer essas configura��es no maven e gradle.

maven

<dependency>
    <groupId>org.junit.platform</groupId>
    <artifactId>junit-platform-launcher</artifactId>
    <version>1.3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.vintage</groupId>
    <artifactId>junit-vintage-engine</artifactId>
    <version>5.3.0</version>
    <scope>test</scope>
</dependency>

gradle

testRuntime("org.junit.platform:junit-platform-launcher:1.3.0")
testRuntime("org.junit.jupiter:junit-jupiter-engine:5.3.0")
testRuntime("org.junit.vintage:junit-vintage-engine:5.3.0")

No Intellij IDEA, quando criamos um projeto do maven, em sua estrutura � adicionada a pasta test. � dentro dela que criamos os pacotes e as classes de teste do projeto.

Escrevendo testes

Escrever uma classe de teste consiste em utilizar alguns m�todos e anota��es da API do JUnit, criando assim pequenos cen�rios nos quais identificamos se o comportamento de uma unidade de trabalho corresponde ao esperado. Aqui voc� ser� apresentado a exemplo reais de teste de software, sendo introduzido passo a passo nos testes unit�rios com JUnit.

Vis�o geral

Em geral, boa parte dos c�digos de teste ser�o criados para implementar algum ou todos os passos a seguir:

Reunir um conjunto de objetos e inici�-los, se necess�rio
Fazer com esses objetos executem suas tarefas de acordo com um contexto
Assegurar que um resultado � aquele esperado

O c�digo abaixo age conforme especificado acima, passando por cada um dos tr�s passos, onde assegurar o resultado esperado � papel desempenhado pelo m�todo est�tico assertEquals.

class Junit5Exemplo {

    @Test
    void meuPrimeiroTeste() {
        assertEquals(2, 1 + 1);
    }
}

Ao longo desta documenta��o veremos outros exemplos de como utilizar os m�todos est�ticos da classe Assertions, os quais s�o parte importante do processo de escrita de testes.

Na pr�tica

Exemplo 1

A primeira anota��o a ser utilizada para criar testes unit�rios � @Test, que informa ao JUnit quais s�o os m�todos de teste de uma classe. Para o JUnit o nome do m�todo n�o importa, pois desde de que ele seja anotado dessa maneira ele ser� identificado como um m�todo de teste.

Nota: Um m�todo anotado com @Test n�o deve retornar um valor.

Considere que estamos trabalhando no m�dulo de vendas em um projeto de software e que como regra de neg�cio um produto jamais possa ser ativado se seu pre�o for menor ou igual a zero. O c�digo que implementa essa regra poderia se parecer com este:

public class ProdutoValidador {

    public void validar(Produto produto) {
        if (produto.getPreco() <= 0 && (produto.getStatus() == null || produto.getStatus() == ProdutoStatus.ATIVO)) {
            throw new ProdutoAtivadoSemPrecoException();
        }
    }
}

Agora, para assegurar a consist�ncia dessa valida��o podemos escrever uma classe de teste e verificar se quando o produto possui pre�o zero e estado ativo a exce��o correspondente ser� lan�ada. Embora seja este o modificador que usamos abaixo, um m�todo ou classe de teste n�o precisa ser p�blico.

public class ProdutoValidadorTest {

    @Test
    @DisplayName("Verifica se um produto est� ativo e possui um pre�o v�lido")
    public void verificaSeProdutoAtivoSemPrecoLancaExcecao() {
        Produto produto = new Produto("Aparelho de Barbear", 10, ProdutoStatus.ATIVO);

        ProdutoValidador validador = new ProdutoValidador();
        assertThrows(ProdutoAtivadoSemPrecoException.class, () -> validador.validar(produto));
    }
}

Nesse cen�rio constru�do para falha � o m�todo assertThrows() quem verifica se obtivemos �xito em fazer com que validar() falhe. Assim como este, existem muitos outros m�todos conhecidos como Assertions, cada um deles escrito para assegurar o retorno de um valor espec�fico.

Exemplo 2

Algumas vezes precisamos utilizar um conjunto de valores nos testes, a fim de verificar em que cen�rios eles ser�o conclu�dos com �xito ou falha. Considere que estamos desenvolvendo uma classe de valida��o de e-mail que ser� utilizada por diversos sistemas conectados a um conjunto de APIs. Existem diversas situa��es em que um e-mail poder� ser considerado inv�lido, podendo um teste parametrizados ajudar a identifica-los.

public class EmailValidadorTest {

    @ParameterizedTest
    @ValueSource(strings = {"", "mail", "mail@mail", "mail@mail.com"})
    public void verificaSeEmailEValido(String email) {
        assertTrue(Email.validar(email));
    }
}

Para escrever um teste parametrizado devemos utilizar a anota��o @ParameterizedTest em conjunto de @ValueSource, assim como exemplificamos abaixo. Nesse caso, ao executarmos os testes o m�todo verificaSeEmailEValido() ser� chamado uma vez para cada par�metro especificado em @ValueSource. Uma vez que apenas o �ltimo valor corresponde a um e-mail v�lido, os tr�s primeiros casos resultar�o em falha.

Exemplo 3

JUnit prov� uma forma de executarmos um teste diversas vezes anotando-o com a anota��o @RepeatedTest, a qual recebe o n�mero repeti��es desejado. Cada execu��o de um m�todo anotado dessa maneira � performada como se estiv�ssemos utilizando a anota��o @Test.

Imagine que desejamos verificar se um segundo salvamento de um produto que possui os mesmos dados de algum anteriormente presente no banco de dados, nome, pre�o, enfim, lan�a uma exce��o indicando uma duplicidade no cadastro.

public class ProdutoRepositorioTest {

    @RepeatedTest(2)
    public void cadastrar() {
        ...
        assertThrows(ProdutoDuplicadoException.class, repositorio.grava(produto));
    }
}

Nesse contexto, � prov�vel que na primeira execu��o este m�todo passe, mas que ele falhe em sua segunda chamada.

Exemplo 4

Uma novidade no JUnit 5 s�o os testes din�micos, que nos permitem criar casos de teste em tempo de execu��o, compostos por um nome e um Executable, dentro de um m�todo de fabrica��o de testes. Com esse recurso podemos usar os dados em uma cole��o como fonte para a cria��o de diferentes contextos de falha, criando um teste para cada um de seus itens dinamicamente, de forma que eles sejam executados pelo JUnit atrav�s de Iterator. Abaixo temos um exemplo onde relacionamos os endere�os e CEPs em duas listas diferentes, passando cada endere�o por servi�o que deve retornar o CEP correspondente.

@TestFactory
public Collection<DynamicTest> testaSeOCepParaUmEnderecoFoiEncontrado() {
    List<String> enderecos =
            new ArrayList<>(Arrays.asList("Rua dos Andrades N 435", ...));

    List<String> ceps =
            new ArrayList<>(Arrays.asList("22343234"...));

    Collection<DynamicTest> dynamicTests = new ArrayList<>();

    for (int i = 0; i < enderecos.size(); i++) {
        String endereco = enderecos.get(i);
        String cep = ceps.get(i);

        Executable executable = () -> assertEquals(cep, Correios.cep(endereco));
        String titulo = "Testando endereco " + endereco;
        DynamicTest dynamicTest = DynamicTest.dynamicTest(titulo, executable);

        dynamicTests.add(dynamicTest);
    }
    
    return dynamicTests;
}

Para item na lista, o objeto Executable, quando executado, far� uma requisi��o atrav�s do servi�o Correios, que deve retornar o CEP que corresponde ao item de mesma posi��o na cole��o de CEPs. Note que este c�digo apenas cria casos de teste, mas ele mesmo n�o os executa. Por conta disso, um m�todo criado dessa maneira deve ser anotado com @TestFactory e retornar uma cole��o de objetos do tipo DynamicTest, que ser�o um a um executados pelo JUnit.

� muito comum vermos testes din�micos serem escritos utilizando express�es lambda. Portanto, segue abaixo uma outra vers�o do c�digo acima, refeito dessa maneira.

@TestFactory
public Iterator<DynamicTest> testaSeOCepParaUmEnderecoFoiEncontrado() {
    List<String> enderecos =
            new ArrayList<>(Arrays.asList("Rua dos Andrades N 435", ...));

    List<String> ceps =
            new ArrayList<>(Arrays.asList("22343234"...));

    return enderecos.stream().map(endereco ->
            DynamicTest.dynamicTest("Testando endereco " + endereco, () -> {
                        int indice = enderecos.indexOf(endereco);
                        assertEquals(ceps.get(indice), Correios.cep(endereco));
                    }
            )).iterator();
}

Exemplo 5

Podemos tamb�m usar testes din�micos para lidar com cen�rios diferentes de falha para um certo grupo de objetos. No caso abaixo desejamos validar se um objeto inv�lido gera uma exce��o para cada uma das formas de inici�-lo a partir de um dos seus construtores.

@TestFactory
public Collection<DynamicTest> testaSeUmUsuarioComDadosInvalidosLancaUmaExcecao() {
    List<Usuario> usuarios = new ArrayList<Usuario>() {{
        add(new Usuario(null, null));
        add(new Usuario(null, ""));
        add(new Usuario("", null));
        add(new Usuario("", ""));
    }};

    Collection<DynamicTest> dynamicTests = new ArrayList<>();

    usuarios.stream().map(usuario ->
            DynamicTest.dynamicTest("Testando usuario " + usuario.getNickname() + " " + usuario.getPassword(), () -> {
                        assertThrows(UsuarioInvalidoException.class, UsuarioValidador.validar(usuario));
                    }
            )).iterator();

    return dynamicTests;
}

Executando classes de teste no Intellij IDEA

Assim como demonstra a imagem abaixo, � poss�vel clicar sobre a pasta test/java e no menu de contexto ser� apresentada a op��o Run 'All Tests', dispon�vel tamb�m no atalho Ctrl+Shift+F10.

Op��o para executar todos os testes

Figura 1. Op��o para executar todos os testes

Com isso, ser�o executados todos os testes escritos nas classes que est�o nesta pasta. N�o se preocupe em como o JUnit identifica uma classe de teste nesse momento, pois veremos isso em detalhes na pr�xima se��o. Ao concluir a execu��o dos testes o Intellij IDEA apresentar� a seguinte janela:

Op��o para executar todos os testes

Figura 2. Teste sendo executado com sucesso.

Ao executar esse teste ele ser� conclu�do com sucesso, pois nessas condi��es a classe ProdutoValidador lan�ar� uma exce��o no m�todo validar(), conforme apresenta a imagem acima.

Ambiente

Uma vez que cada teste deve ser executado de forma isolada e independente, a fim de garantir que eles n�o sofram com a aus�ncia de depend�ncias ou a sobra de inst�ncias de objetos usados em testes anteriores, � importante que saibamos utilizar os mecanismos dispon�veis para a cria��o e destrui��o de ambientes isolados de teste, assunto tratado nesta se��o da documenta��o.

Vis�o geral

Grandes aplica��es costumam executar seus testes de forma aut�noma, em um processo que pode durar horas at� que todo o sistema esteja coberto por eles. Nesse contexto, � importante que cada teste na pilha possa ser executado sem nenhuma conex�o com o anterior como uma garantia de que a falha em um determinado teste n�o comprometer� a confiabilidade dos seguintes. De outra forma, pode ser necess�rio rastrear a origem problemas como testes que falham dependendo da ordem em que s�o executados, o que pode facilmente consumir algumas horas do programador.

Assim, podemos concluir que um teste confi�vel deve:

Iniciar objetos e depend�ncias
Executar as a��es necess�rias para a avalia��o de um resultado
Remover objetos e depend�ncias da mem�ria

Uma alternativa para evitar esse e outros cen�rios ca�ticos onde haja alguma interdepend�ncia entre dois ou mais testes o JUnit oferece dois mecanismos, @BeforeEach e @AfterEach. @BeforeEach, o m�todo da classe que � executado antes de cada teste, nos permite inicializar objetos ou realizar qualquer tarefa relacionada a prepara��o de um ambiente adequado para que os objetos reunidos em um contexto executem as suas a��es de forma consistente e isolada. @AfterEach desfaz esse ambiente, removendo da mem�ria caches, fechando streams ou quaisquer outros dados que poderiam comprometer a confiabilidade do pr�ximo teste.

Tanto @BeforeEach quanto @AfterEach podem ser utilizados com as anota��es @Test, @RepeatedTest, @ParameterizedTest ou @TestFactory.

Na pr�tica

Exemplo 1

Embora seja um recurso �til, devemos evitar utilizar as anota��es @BeforeEach e @AfterEach quando forem desnecess�rias, uma vez que elas podem tornar a leitura do c�digo mais dif�cil, visto que para acompanhar o que ele faz o programador dever� dividir a sua aten��o entre alguns m�todos. Abaixo vemos um caso no qual utilizar essas anota��es � algo dispens�vel e indevido.

class TestaDeValidadeDoArquivoDeLog {

    private Logger logger;

    @BeforeEach
    public void setUp() {
        logger = // Inicia o log
    }

    @Test
    public void testaSeOArquivoDeLogEValido() {
        ...
        assertTrue("Arquivo de log invalido", logger.validaArquivoDeLog("20181110.log"));
        ...
    }

    @AfterEach
    public void tearDown() {
        logger = null; // Instru��o desnecess�ria
    }
}

Uma outra vers�o do c�digo acima pode ser obtida da seguinte forma:

class TestaDeValidadeDoArquivoDeLog {

    private Logger logger;

    @Test
    public void testaSeOArquivoDeLogEValido() {
        logger = criaLoggerParaTeste();
        ...
        assertTrue("Arquivo de log invalido", logger.validaArquivoDeLog("20181110.log"));
        ...
    }

    public Logger criaLoggerParaTeste() {
        return Logger.getLogger(getClass().getCanonicalName());
    }
}

Nesta nova vers�o do c�digo a cada vez que precisamos de uma nova inst�ncia de Logger solicitamos ao m�todo de f�brica que gere uma nova, dessa forma descartando a anterior.

Exemplo 2

De acordo com Osherove, uma das aplica��es justific�veis para esse mecanismo � o desfazimento de estados globais, geralmente associados a objetos est�ticos, como singletons. De acordo com ele, se necessitamos iniciar ou destruir objetos espec�ficos desta forma estamos nos aproximando de testes de integra��o, o que n�o deveria ser uma preocupa��o nesse momento, sendo implementado em um pr�ximo projeto de testes.

Para ilustrar esse cen�rio, considere que estamos escrevendo um c�digo de testes no qual necessitamos utilizar alguns objetos est�ticos, criados a partir de um Singleton. Uma vez que esses objetos n�o ser�o removidos da mem�ria ou recriados automaticamente ap�s encerrado o escopo dos m�todos de teste, passa a ser necess�rio tratar a mem�ria de alguma outra forma. No exemplo a seguir reiniciamos esses objetos globais com as anota��es @BeforeEach e @AfterEach, destruindo qualquer resqu�cio de dado que poderia comprometer os pr�ximos testes que utilizam os mesmos.

class TestaCadastroDeUsuarioJaCadastrado {

    private EntityManager em;

    @Test
    public void testaSeOArquivoDeLogEValido() {
        em = JpaUtil.getEntityManager();
        ...
        assertThrows(EmailJaCadastradoException.class, em.persist(usuario));
        ...
        em.close();
    }

    @AfterEach
    public void tearDown() {
        em = null;
    }
}

Perceba que tarefas de rotina, como a inicializa��o do EntityManager e o fechamento da sess�o s�o realizadas em um mesmo contexto, dentro do m�todo de teste. Outras a��es, como a destrui��o desse objeto e quaisquer informa��es vinculadas ou mantidas por ele ficam ao encargo da API, que chamar�, ap�s cada um dos testes, o m�todo para destrui��o do ambiente de teste.

Assertions

A classe Assertions � uma cole��o de m�todos que afirmam se certas condi��es comuns em testes correspondem ao esperado.

Vis�o geral

Os m�todos est�ticos da classe Assertions s�o parte importante dos casos de teste e avaliam se certas condi��es, decisivas para determinar o sucesso ou falha do teste, geram um resultado esperado. Geralmente esses m�todos lan�am uma exce��o do tipo AssertionFailedError.

import static org.junit.jupiter.api.Assertions.*;
...
assertEquals(2026.43, funcionario.getSalarioLiquido());
assertEquals(2026.43, funcionario.getSalarioLiquido(), "Compara��o de sal�rio l�quido ap�s descontos");
...

Tem se tornado uma conven��o entre os desenvolvedores usar import static em lugar de utilizar o nome da classe para acessar os seus m�todos est�ticos. Para isso podemos utilizar a seguinte declara��o:

Principais m�todos da classe Assertions

assertTrue

Requer que a condi��o booleana seja verdadeira.

public static void assertTrue(boolean condition)

public static void assertTrue(boolean condition,
    Supplier<String> messageSupplier)

public static void assertTrue(BooleanSupplier booleanSupplier)

public static void assertTrue(BooleanSupplier booleanSupplier,
    String message)

public static void assertTrue(boolean condition,
    String message)

public static void assertTrue(BooleanSupplier booleanSupplier,
    Supplier<String> messageSupplier)

assertFalse

Requer que a condi��o booleana seja falsa.

public static void assertFalse(boolean condition)

public static void assertFalse(boolean condition,
    String message)

public static void assertFalse(boolean condition,
    Supplier<String> messageSupplier)

public static void assertFalse(BooleanSupplier booleanSupplier)

public static void assertFalse(BooleanSupplier booleanSupplier,
    String message)

public static void assertFalse(BooleanSupplier booleanSupplier,
    Supplier<String> messageSupplier)

assertNull

Requer que o valor informado como par�metro seja nulo.

public static void assertNull(Object actual)

public static void assertNull(Object actual,
    String message)

public static void assertNull(Object actual,
    Supplier<String> messageSupplier)

assertNotNull

Requer que o valor informado como par�metro n�o seja nulo.

public static void assertNotNull(Object actual)

public static void assertNull(Object actual,
    String message)

public static void assertNotNull(Object actual,
    String message)

public static void assertNotNull(Object actual,
    Supplier<String> messageSupplier)

assertEquals

Requer que ambos os valores passados como par�metro sejam verdadeiros.

public static void assertEquals(short expected,
    short actual)

public static void assertEquals(short expected,
    short actual, String message)

public static void assertEquals(short expected,
    short actual, Supplier<String> messageSupplier)

public static void assertEquals(byte expected,
    byte actual)

public static void assertEquals(byte expected,
    byte actual, String message)

public static void assertEquals(byte expected,
    byte actual, Supplier<String> messageSupplier)

public static void assertEquals(int expected,
    int actual)

public static void assertEquals(int expected,
    int actual, String message)

public static void assertEquals(int expected,
    int actual, Supplier<String> messageSupplier)

public static void assertEquals(long expected,
    long actual)

public static void assertEquals(long expected,
    long actual, String message)

public static void assertEquals(long expected,
    long actual, Supplier<String> messageSupplier)

public static void assertEquals(char expected,
    char actual)

public static void assertEquals(char expected,
    char actual, String message)

public static void assertEquals(char expected,
    char actual, Supplier<String> messageSupplier)

public static void assertEquals(float expected,
    float actual)

public static void assertEquals(float expected,
    float actual, String message)

public static void assertEquals(float expected,
    float actual, Supplier<String> messageSupplier)

public static void assertEquals(float expected,
    float actual, float delta)

public static void assertEquals(float expected,
    float actual, float delta, String message)

public static void assertEquals(float expected,
    float actual, float delta, Supplier<String> messageSupplier)

public static void assertEquals(double expected,
    double actual)

public static void assertEquals(double expected,
    double actual, String message)

public static void assertEquals(double expected,
    double actual, Supplier<String> messageSupplier)

public static void assertEquals(double expected,
    double actual, double delta)

public static void assertEquals(double expected,
    double actual, double delta, String message)

public static void assertEquals(double expected,
    double actual, double delta, Supplier<String> messageSupplier)

public static void assertEquals(Object expected,
    Object actual)

public static void assertEquals(Object expected,
    Object actual, String message)

public static void assertEquals(Object expected,
    Object actual, Supplier<String> messageSupplier)

assertArrayEquals

Requer que ambos os vetores sejam iguais.

public static void assertArrayEquals(boolean[] expected,
    boolean[] actual)

public static void assertArrayEquals(boolean[] expected,
    boolean[] actual, String message)

public static void assertArrayEquals(boolean[] expected,
    boolean[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(char[] expected,
    char[] actual)

public static void assertArrayEquals(char[] expected,
    char[] actual, String message)

public static void assertArrayEquals(char[] expected,
    char[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(byte[] expected,
    byte[] actual)

public static void assertArrayEquals(byte[] expected,
    byte[] actual, String message)

public static void assertArrayEquals(byte[] expected,
    byte[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(short[] expected,
    short[] actual)

public static void assertArrayEquals(short[] expected,
    short[] actual, String message)

public static void assertArrayEquals(short[] expected,
    short[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(int[] expected,
    int[] actual)

public static void assertArrayEquals(int[] expected,
    int[] actual, String message)

public static void assertArrayEquals(int[] expected,
    int[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(long[] expected,
    long[] actual)

public static void assertArrayEquals(long[] expected,
    long[] actual, String message)

public static void assertArrayEquals(long[] expected,
    long[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(float[] expected,
    float[] actual)

public static void assertArrayEquals(float[] expected,
    float[] actual, String message)

public static void assertArrayEquals(float[] expected,
    float[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(float[] expected,
    float[] actual, float delta)

public static void assertArrayEquals(float[] expected,
    float[] actual, float delta, String message)

public static void assertArrayEquals(float[] expected,
    float[] actual, float delta, Supplier<String> messageSupplier)

public static void assertArrayEquals(double[] expected,
    double[] actual)

public static void assertArrayEquals(double[] expected,
    double[] actual, String message)

public static void assertArrayEquals(double[] expected,
    double[] actual, Supplier<String> messageSupplier)

public static void assertArrayEquals(double[] expected,
    double[] actual, double delta)

public static void assertArrayEquals(double[] expected,
    double[] actual, double delta, String message)

public static void assertArrayEquals(double[] expected,
    double[] actual, double delta, Supplier<String> messageSupplier)

public static void assertArrayEquals(Object[] expected,
    Object[] actual)

public static void assertArrayEquals(Object[] expected,
    Object[] actual, String message)

public static void assertArrayEquals(Object[] expected,
    Object[] actual, Supplier<String> messageSupplier)

assertIterableEquals

Requer que todos os objetos do tipo Iterable passados como par�metro sejam iguais.

public static void assertIterableEquals(Iterable<?> expected,
    Iterable<?> actual)

public static void assertIterableEquals(Iterable<?> expected,
    Iterable<?> actual, String message)

public static void assertIterableEquals(Iterable<?> expected,
    Iterable<?> actual, Supplier<String> messageSupplier)

assertLinesMatch

Requer que ambas as listas de strings sejam iguais.

public static void assertLinesMatch(List<String> expectedLines,
    List<String> actualLines)

assertNotEquals

Requer que ambos os valores passados como par�metro sejam iguais.

public static void assertNotEquals(Object unexpected,
    Object actual)

public static void assertNotEquals(Object unexpected,
    Object actual, String message)

public static void assertNotEquals(Object unexpected,
    Object actual, Supplier<String> messageSupplier)

assertSame

Requer que ambos os par�metros se refiram ao mesmo objeto.

public static void assertSame(Object expected,
    Object actual)

public static void assertSame(Object expected,
    Object actual, String message)

public static void assertSame(Object expected,
    Object actual, Supplier<String> messageSupplier)

assertNotSame

Requer que ambos os par�metros se refiram a objetos diferentes.

public static void assertNotSame(Object unexpected,
    Object actual)

public static void assertNotSame(Object unexpected,
    Object actual, String message)

public static void assertNotSame(Object unexpected,
    Object actual, Supplier<String> messageSupplier)

assertAll

Requer que todos os objetos do tipo Executable passados como par�metro n�o lan�am exce��es.

public static void assertAll(Executable... executables)
    throws MultipleFailuresError

public static void assertAll(Stream<Executable> executables)
    throws MultipleFailuresError

public static void assertAll(String heading, Executable... executables)
    throws MultipleFailuresError

public static void assertAll(String heading, Stream<Executable> executables)
    throws MultipleFailuresError

assertThrows

Requer que a execu��o do objeto do tipo Executable passado como par�metro lance um exce��o do tipo esperado.

public static <T extends Throwable> T assertThrows(Class<T> expectedType,
    Executable executable)

public static <T extends Throwable> T assertThrows(Class<T> expectedType,
    Executable executable, String message)

public static <T extends Throwable> T assertThrows(Class<T> expectedType,
    Executable executable, Supplier<String> messageSupplier)

assertTimeout

Requer que uma execu��o se complete antes do tempo estimado.

public static void assertTimeout(Duration timeout,
    Executable executable)

public static void assertTimeout(Duration timeout,
    Executable executable, String message)

public static void assertTimeout(Duration timeout,
    Executable executable, Supplier<String> messageSupplier)

public static <T> T assertTimeout(Duration timeout,
    ThrowingSupplier<T> supplier)

public static <T> T assertTimeout(Duration timeout,
    ThrowingSupplier<T> supplier, String message)

public static <T> T assertTimeout(Duration timeout,
    ThrowingSupplier<T> supplier, Supplier<String> messageSupplier)

assertTimeoutPreemptively

Requer que uma execu��o se complete ap�s do tempo estimado.

public static void assertTimeoutPreemptively(Duration timeout,
    Executable executable)

public static void assertTimeoutPreemptively(Duration timeout,
    Executable executable, String message)

public static void assertTimeoutPreemptively(Duration timeout,
    Executable executable, Supplier<String> messageSupplier)

public static <T> T assertTimeoutPreemptively(Duration timeout,
    ThrowingSupplier<T> supplier)

public static <T> T assertTimeoutPreemptively(Duration timeout,
    ThrowingSupplier<T> supplier, String message)

public static <T> T assertTimeoutPreemptively(Duration timeout,
    ThrowingSupplier<T> supplier, Supplier<String> messageSupplier)

Confira outros conte�dos:

Introdu��o ao JDBC

Novidades do Java

Jakarta EE, o futuro do Java EE

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Estev�o Em 2020

Coment�rios nesta publica��o Escrever um coment�rio sobre conte�do

Henrique Marco

N�vel 0

bom dia estou com dificuldade para testar um CRUD de uma api com JUnit, podem me ajudar?

há +1 ano

Ver coment�rios anteriores (2)

Marcio Souza

DevMedia

Opa!

Quando usamos JUnit os testes em cima de listas ou arrays s�o baseados no tamanho deles.

Por exemplo, voc� vai testar a consulta que busca todas as pessoas que vivem na cidade de S�o Paulo. Se voc� tiver no banco de dados 20 pessoas, o resultado do teste tem que ser 20. Ou seja, o tamanho da lista ou do array deve ser 20.

Voc� precisa conhecer os registros que tem na base de dados para realizar os testes, por isso, � importante ter uma base de testes. Essa base n�o deve ser alterada nunca, para que os testes j� realizados n�o resultem em testes errados a pr�xima vez que forem executados.

O que normalmente fazemos � criar a base em mem�ria, usando um banco de dados do tipo Derby DB, H2 ou HSQLDB. Criamos um script que � carregado em tempo de execu��o toda vez que um teste � executado. Quando o teste � encerrado a base � eliminada da mem�ria. Assim, mesmo que tenha inserido, removido ou alterado algum registro, na pr�xima vez que os testes forem executados a base n�o ter� essas manipula��es.

há +1 ano

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso

Teste unit�rio com JUnit

JUnit � uma API de c�digo aberto para a cria��o de testes unit�rios em Java, bem como outras linguagem compat�veis com a JVM.

Vis�o geral

Instala��o

maven

gradle

Configura��o

maven

gradle

Escrevendo testes

Vis�o geral

Na pr�tica

Exemplo 1

Exemplo 2

Exemplo 3

Exemplo 4

Exemplo 5

Executando classes de teste no Intellij IDEA

Ambiente

Vis�o geral

Na pr�tica

Exemplo 1

Exemplo 2

Assertions

Vis�o geral

Principais m�todos da classe Assertions

assertTrue

assertFalse

assertNull

assertNotNull

assertEquals

assertArrayEquals

assertIterableEquals

assertLinesMatch

assertNotEquals

assertSame

assertNotSame

assertAll

assertThrows

assertTimeout

assertTimeoutPreemptively

Confira outros conte�dos:

Introdu��o ao JDBC

Novidades do Java

Jakarta EE, o futuro do Java EE

Perguntas frequentes

Nossos casos de sucesso