Questão de Engenharia de Software — Conceitos e Tipos de Testes de Software — VUNESP 2025
Engenharia de Software›Conceitos e Tipos de Testes de Software
Código
vu222964
Banca
VUNESP
Órgão
TJ SP
Ano
2025
Cargo
AnaSistJ ( )
Considerando a implementação dos chamados mocks e stubs, é correto afirmar que, por definição,
A stub é uma implementação que tem como retorno um valor fixo, pré-definido, quando ocorre a chamada a uma função.
Bstub é configurado para retornar diferentes respostas, de acordo com os parâmetros de entrada recebidos.
Cstub e mock aplicam-se apenas a software cuja finalidade é o acesso a bases de dados.
Dstub e mock não se aplicam a software voltado ao desenvolvimento de interfaces humano-computador.
Emock, normalmente, é uma implementação que tem como retorno um valor fixo, pré-definido, quando ocorre a chamada a uma função
Revelar gabarito e comentário▾
GabaritoA — stub é uma implementação que tem como retorno um valor fixo, pré-definido, quando ocorre a chamada a uma função.
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”.
Mocks e Stubs em Testes de Software
Gabarito: letra A. Por definição, um stub é uma implementação simplificada que retorna um valor fixo e pré-definido quando uma função é chamada, servindo para isolar o código sob teste de dependências externas. O mock, por sua vez, é um objeto mais sofisticado que pode ser configurado para verificar interações e retornar respostas diferentes conforme os parâmetros de entrada — é exatamente essa distinção que a alternativa correta espelha.
No contexto de testes de software, mocks e stubs são objetos de teste (test doubles) usados para substituir dependências reais de um componente, permitindo que o teste se concentre no comportamento da unidade sob verificação. A necessidade surge porque, em testes de unidade, queremos isolar o código testado de fatores externos — como bancos de dados, serviços web, sistemas de arquivos ou outras classes — que poderiam tornar o teste lento, instável ou difícil de controlar.
A diferença fundamental entre eles está no nível de sofisticação e no propósito: o stub é a forma mais simples, um "dublê" que apenas devolve uma resposta fixa para permitir que o teste prossiga; o mock vai além, registrando as chamadas feitas a ele e permitindo que o teste verifique se determinadas interações ocorreram (como "o método X foi chamado com os argumentos Y"). Essa distinção é clássica na literatura de engenharia de software e é amplamente cobrada em concursos.
Na prática, imagine testar uma classe PedidoService que depende de um repositório de banco de dados. Para testar apenas a lógica de negócio do serviço, você pode criar um stub do repositório que sempre retorna um pedido fictício com valor fixo — assim o teste não depende do banco real. Se você quiser verificar se o serviço realmente chamou o método salvar() do repositório ao processar um pedido, você usaria um mock, que registra essa chamada e permite a asserção.
A pegadinha que a banca explora aqui é a inversão de papéis: a alternativa E atribui ao mock a característica de retorno fixo (que é do stub), enquanto a alternativa B atribui ao stub a capacidade de responder dinamicamente conforme parâmetros (que é característica do mock). Guarde a fronteira: stub = resposta fixa e pré-definida; mock = comportamento configurável e verificação de interações.
Test doubles: Stub (Retorno fixo e pré-definido, Isola dependências externas); Mock (Respostas conforme parâmetros, Verifica interações (chamadas)); Aplicação (Bancos de dados, Serviços web, Interfaces (IHC))
Alternativa A — ✅ Correta ⟵ GABARITO
Esta é a definição clássica de stub: uma implementação que, ao ser chamada, retorna um valor fixo e pré-definido, sem lógica adicional. O objetivo é simplesmente "tapar o buraco" da dependência para que o teste possa executar. É exatamente o que a alternativa descreve, e por isso está correta.
Alternativa B — ❌ Incorreta
A alternativa atribui ao stub a capacidade de retornar diferentes respostas conforme os parâmetros de entrada. Essa é uma característica do mock, que pode ser programado para responder de forma dinâmica e até verificar se foi chamado corretamente. O stub, por definição, é mais simples e retorna sempre o mesmo valor pré-definido, independentemente dos argumentos recebidos.
Alternativa C — ❌ Incorreta
Afirma que stub e mock se aplicam apenas a software cuja finalidade é o acesso a bases de dados. Isso é falso: mocks e stubs são técnicas genéricas de teste, aplicáveis a qualquer tipo de dependência externa — serviços web, APIs, sistemas de arquivos, filas de mensagens, entre outros. Não há restrição a bancos de dados.
Alternativa D — ❌ Incorreta
Afirma que stub e mock não se aplicam a software voltado ao desenvolvimento de interfaces humano-computador (IHC). Isso também é falso: em testes de interface, é comum usar mocks para simular serviços de backend ou stubs para simular componentes de UI ainda não implementados. A técnica é universal no desenvolvimento de software.
Alternativa E — ❌ Incorreta
Esta alternativa inverte os papéis: atribui ao mock a característica de retorno fixo e pré-definido, que é própria do stub. O mock é mais sofisticado — pode ser configurado para retornar respostas diferentes conforme os parâmetros e, principalmente, permite verificar se as interações esperadas ocorreram. A banca troca deliberadamente os conceitos para confundir o candidato.
NÃO CAIA NESSA!
A banca adora inverter os papéis entre stub e mock. Lembre-se: stub = resposta fixa (simples, "tapa-buraco"); mock = comportamento configurável + verificação de interações. Se a alternativa falar em "retorno fixo", é stub; se falar em "verificar chamadas" ou "responder conforme parâmetros", é mock. Com esse critério, você elimina as pegadinhas de longe 💪