Questão de Programação — Programação Orientada a Objetos — FUNDATEC 2026

Testes unitários com JUnit 5: verificando comportamento e exceções

Gabarito: letra C. O teste unitário apresentado verifica dois comportamentos do método sacar: a atualização correta do saldo (por meio de assertEquals) e o lançamento de exceção quando o saldo é insuficiente (por meio de assertThrows). A alternativa C descreve exatamente essa dupla verificação, que é o padrão típico de testes unitários em Java com JUnit 5.

O teste unitário é uma técnica de teste de software que verifica o funcionamento de uma unidade isolada de código — em geral, um método de uma classe. No contexto de Programação Orientada a Objetos, essa unidade é um método de uma classe, como o método sacar de uma classe Conta. O objetivo é garantir que o método se comporte conforme o esperado em diferentes cenários: quando os parâmetros são válidos, quando há condições de contorno, e quando há condições de erro.

No JUnit 5, as asserções são feitas por métodos estáticos da classe org.junit.jupiter.api.Assertions. Os dois mais relevantes para esta questão são:

• assertEquals(valorEsperado, valorAtual): verifica se dois valores são iguais. No teste, é usado para confirmar que, após uma operação de saque, o saldo da conta é exatamente o valor esperado. Esse método funciona com qualquer tipo de objeto, incluindo tipos numéricos como double e int — não há restrição para valores numéricos.

• assertThrows(TipoExcecao.class, () -> metodo()): verifica se a execução de um trecho de código (geralmente uma expressão lambda) lança uma exceção do tipo especificado. No teste, é usado para confirmar que o método sacar lança uma exceção quando o saldo é insuficiente.

A combinação dessas duas asserções em um único teste é uma prática comum e recomendada: primeiro, verifica-se o comportamento feliz (o saldo é atualizado corretamente); depois, verifica-se o comportamento de erro (a exceção é lançada). Isso aumenta a confiança de que o método está implementado corretamente em ambos os cenários.

Um ponto importante é que o teste unitário trabalha com uma instância da classe em memória. As alterações feitas no objeto durante o teste (como a mudança de saldo) não persistem após o término da execução do teste — elas são descartadas quando o objeto é destruído ou quando a JVM encerra. Portanto, o teste não altera permanentemente o saldo da conta em nenhum sistema externo ou banco de dados.

A pegadinha desta questão está em alternativas que descrevem apenas uma parte do que o teste faz, ou que afirmam comportamentos incorretos sobre o JUnit. A alternativa C é a única que descreve corretamente o escopo completo do teste: verificar tanto a atualização do saldo quanto o lançamento de exceção.

Alternativa A — ❌ Incorreta

Afirma que o teste falha porque o método sacar não permite valores negativos. Essa afirmação é incorreta por dois motivos. Primeiro, o teste não falha — ele é projetado para verificar comportamentos esperados, e a alternativa C (gabarito) confirma que o teste verifica tanto a atualização do saldo quanto o lançamento de exceção. Segundo, a questão não fornece informações sobre a implementação do método sacar em relação a valores negativos; o teste unitário apresentado não menciona essa validação. A alternativa inventa um comportamento que não está no escopo do teste.

Alternativa B — ❌ Incorreta

Afirma que o teste verifica apenas se uma exceção é lançada pelo método sacar. Essa afirmação é incompleta. O teste, conforme descrito na alternativa C (gabarito), verifica tanto a atualização correta do saldo quanto o lançamento de exceção. A alternativa B ignora a parte do teste que usa assertEquals para verificar o saldo, focando apenas na parte que usa assertThrows. O teste é mais abrangente do que a alternativa B descreve.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta alternativa descreve corretamente o que o teste unitário faz. O teste verifica a atualização correta do saldo usando assertEquals (comparando o saldo esperado com o saldo atual após a operação de saque) e verifica o lançamento de exceção quando o saldo é insuficiente usando assertThrows. Essa é a descrição completa e precisa do escopo do teste, cobrindo tanto o comportamento feliz quanto o comportamento de erro do método sacar.

Alternativa D — ❌ Incorreta

Afirma que o teste falha porque o método assertEquals não pode ser usado com valores numéricos. Essa afirmação é falsa. O método assertEquals do JUnit 5 pode ser usado com qualquer tipo de objeto, incluindo tipos numéricos como int, double, float, etc. Na verdade, o JUnit 5 oferece sobrecargas de assertEquals para tipos primitivos numéricos, como assertEquals(int, int) e assertEquals(double, double). Portanto, não há nenhuma restrição que impeça o uso de assertEquals com valores numéricos.

Alternativa E — ❌ Incorreta

Afirma que o teste altera permanentemente o saldo da conta no sistema. Essa afirmação é incorreta. O teste unitário trabalha com uma instância da classe Conta criada em memória durante a execução do teste. As alterações feitas nessa instância (como a mudança de saldo) são locais ao objeto e não persistem após o término do teste. O teste não interage com nenhum sistema externo, banco de dados ou armazenamento persistente. Portanto, o saldo da conta não é alterado permanentemente em nenhum sistema.

Gabarito: letra C