Questão de Engenharia de Software — Geral — FUNDATEC 2026
Engenharia de Software›Geral
Código
qa433479
Banca
FUNDATEC
Órgão
IFC
Ano
2026
Cargo
PEBTT ( )
Analise a seguinte classe escrita em Java (Java SE) 11:
public class Conta { private double saldo; public Conta(double saldoInicial) { this.saldo = saldoInicial; } public void sacar(double valor) { if(valor > saldo) { throw new IllegalArgumentException("Saldo insuficiente"); } saldo -= valor; } public double getSaldo() { return saldo; } }
Considere também o seguinte teste unitário utilizando JUnit 5 (org.junit.jupiter.api):
import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test; public class ContaTest { @Test void testeSaque() { Conta conta = new Conta(100); conta.sacar(40); assertEquals(60, conta.getSaldo()); assertThrows(IllegalArgumentException.class, () -> { conta.sacar(100); }); } }
Sobre a execução do teste unitário apresentado, assinale a alternativa correta.
AO teste falha porque o método sacar não permite valores negativos.
BO teste verifica apenas se uma exceção é lançada pelo método sacar.
CO teste verifica tanto a atualização correta do saldo quanto o lançamento de exceção quando o saldo é insuficiente.
DO teste falha porque o método assertEquals não pode ser usado com valores numéricos.
EO teste altera permanentemente o saldo da conta no sistema.
Revelar gabarito e comentário▾
GabaritoC — O teste verifica tanto a atualização correta do saldo quanto o lançamento de exceção quando o saldo é insuficiente.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Teste unitário com JUnit 5: verificando comportamento e exceções
Gabarito: letra C. O teste unitário apresentado verifica dois comportamentos do método sacar: primeiro, que o saldo é atualizado corretamente após um saque válido (via assertEquals), e segundo, que uma exceção é lançada quando o saque é maior que o saldo disponível (via assertThrows). A alternativa C descreve exatamente essa dupla verificação, que é o objetivo central do teste.
O teste unitário é uma prática fundamental da engenharia de software, focada em validar o funcionamento de um componente isoladamente — no caso, a classe Conta. O objetivo é garantir que cada unidade do sistema (métodos, classes) se comporte conforme o especificado, tanto nos cenários de sucesso quanto nos de falha. No teste apresentado, temos dois cenários distintos sendo exercitados: um saque válido (R$ 40 de um saldo de R$ 100) e um saque inválido (R$ 100 de um saldo de R$ 60).
O primeiro cenário testa o comportamento feliz (happy path): após conta.sacar(40), o saldo deve ser 60. O assertEquals(60, conta.getSaldo()) verifica exatamente isso — que o método sacar subtrai corretamente o valor do saldo. O segundo cenário testa o comportamento de erro: ao tentar sacar R$ 100 com apenas R$ 60 de saldo, o método sacar deve lançar uma IllegalArgumentException. O assertThrows verifica que essa exceção é de fato lançada, confirmando que a validação de saldo insuficiente está funcionando.
É importante notar que o teste não verifica apenas um aspecto, mas sim dois: a correta atualização do saldo e o lançamento da exceção. Isso é uma boa prática de teste unitário — cobrir tanto o caminho feliz quanto o caminho de erro, garantindo que o componente se comporte adequadamente em todas as situações previstas. A alternativa C captura essa essência, enquanto as demais ou descrevem apenas parte do que o teste faz, ou apresentam afirmações incorretas sobre o funcionamento do código.
A pegadinha desta questão está em interpretar o teste como se ele verificasse apenas um dos comportamentos, ignorando o outro. O candidato que lê rapidamente pode pensar que o teste só valida a exceção (alternativa B) ou só a atualização do saldo, mas na verdade ele valida ambos. A chave é perceber que o teste contém duas asserções independentes: uma para o saldo e outra para a exceção.
1Cria Conta com saldo 100
2Saca 40 (válido)
3Verifica saldo = 60
4Tenta sacar 100 (inválido)
5Verifica exceção lançada
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
O teste não falha, ele passa com sucesso. A afirmação de que o método sacar não permite valores negativos é verdadeira (o código não trata valores negativos explicitamente, mas a validação if(valor > saldo) impede saques maiores que o saldo, e valores negativos não são o foco do teste). No entanto, o teste não falha por isso — ele executa com sucesso, pois os cenários testados são válidos e as asserções são atendidas. O erro da alternativa está em afirmar que o teste falha, quando na verdade ele passa.
Alternativa B — ❌ Incorreta
O teste não verifica apenas se uma exceção é lançada. Ele também verifica a atualização correta do saldo através do assertEquals(60, conta.getSaldo()). A alternativa descreve apenas uma parte do que o teste faz, ignorando a primeira asserção. O teste é composto por duas verificações: uma de comportamento normal (saldo atualizado) e uma de comportamento de erro (exceção lançada).
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa descreve com precisão o que o teste faz. O assertEquals(60, conta.getSaldo()) verifica que o saldo foi atualizado corretamente após o saque de R$ 40, e o assertThrows(IllegalArgumentException.class, ...) verifica que a exceção é lançada quando se tenta sacar R$ 100 com apenas R$ 60 de saldo. O teste cobre ambos os cenários: o sucesso (saque válido) e a falha (saque com saldo insuficiente).
Alternativa D — ❌ Incorreta
O assertEquals pode sim ser usado com valores numéricos. Na verdade, assertEquals é sobrecarregado para vários tipos, incluindo int, double, long, etc. No código, assertEquals(60, conta.getSaldo()) compara o valor esperado (60) com o valor retornado pelo método getSaldo(), que é um double. O JUnit 5 trata essa comparação corretamente, então o teste não falha por esse motivo. A alternativa apresenta uma afirmação falsa sobre a API do JUnit.
Alternativa E — ❌ Incorreta
O teste não altera permanentemente o saldo da conta no sistema. O teste cria uma nova instância de Conta com saldo inicial de 100, realiza operações sobre essa instância e verifica os resultados. Ao final do teste, a instância é descartada (não há referência persistente). O teste não interage com nenhum sistema externo ou banco de dados — ele apenas valida o comportamento da classe em memória. A afirmação de que o saldo é alterado permanentemente no sistema é incorreta, pois o teste é isolado e não tem efeitos colaterais fora do escopo do próprio teste.