Ainda a respeito de engenharia de software, assinale a opçã...

Alternativa correta: D - Os mock objects podem auxiliar os testes unitários utilizados para simular funcionalidades, uma vez que são objetos com a mesma interface que os objetos externos.

A questão aborda conceitos importantes sobre testes de software dentro do contexto da engenharia de software. Para resolver essa questão, é necessário entender os diferentes tipos de testes e suas respectivas finalidades. Vamos agora entender por que a alternativa D é a correta e o que ela implica.

Os mock objects são utilizados em testes unitários para simular o comportamento de objetos reais complexos de forma controlada. Eles são particularmente úteis em situações onde os objetos reais são difíceis de incorporar em testes (por exemplo, objetos que requerem configuração de rede ou banco de dados). O uso de mock objects permite ao desenvolvedor focar no código que está sendo testado, sem se preocupar com o resto do sistema. Isso facilita tanto a escrita de testes quanto a identificação de erros.

Além disso, os mock objects são projetados para imitar a interface dos objetos que eles estão substituindo, o que significa que do ponto de vista do código em teste, eles parecem ser o objeto real. Isso é benéfico porque o código pode ser testado de forma isolada e consistente, sem depender de fatores externos.

Essa abordagem permite testar o comportamento esperado do código em teste, em resposta a várias condições simuladas. Por exemplo, você pode usar um mock object para simular uma resposta de um serviço web que está temporariamente indisponível ou para simular exceções para testar a robustez do código. A alternativa D é correta porque reconhece a utilidade dos mock objects como uma ferramenta para melhorar a eficácia dos testes unitários.

Ai vai um pouco de teoria tirada do blog http://www.sergiodias.inf.br/engenharia-de-software/qualidade

Quanto à forma como são executados:

• Testes de Caixa Preta: executados com o sistema complemente montado e utilizando as interfaces externas providas pela aplicação;
• Testes de Caixa Branca: executado pelo desenvolvedor, com o sistema “aberto”, permite o teste de interfaces internas e em condições de configuração inexistentes quando o sistema está montado;

• Testes de Funcionalidade ou testes funcionais, que verificam se os requisitos funcionais do projeto foram atendidos;
• Testes de Sistema ou Não Funcionais, validam os requisitos não funcionais da aplicação;
• Testes de Regressão, ou Regressivos: consiste em testar apenas as funcionalidades que não foram afetadas (ou não deveriam ter sido) pela nova versão do sistema: “Tudo deve funcionar como antes”;
• Testes de Progressão, ou Progressivos: testes apenas das funcionalidades (ou requisitos não funcionais) especificados para a versão;

• Testes Unitários: aplicados pelos desenvolvedores, validam o funcionamento de componentes isolados do sistema. Atualmente este tipo de teste tem sido muito utilizado com automação de testes em frameworks como o JUnit;
• Testes de Integração: realizados na fase de integração do desenvolvimento, tem como objetivo validar a integração entre as camadas ou componentes do sistema;
• Testes Integrados: típicos testes de Caixa Preta realizados quando uma versão do sistema foi liberada;
• Teste de Aceite, também chamado de Homologação, consiste nos testes realizados para validar os requisitos do Cliente e que condicionarão a aceitação da versão para entrada em produção;

• Teste de Carga: consiste em levar o sistema todo ao limite de carga do software e da infra-estrutura, medindo a capacidade de carga total deste sistema. Este é um teste que precisa necessariamente ser automatizado;
• Teste de Stress:  comumente confundido com o Teste de Carga, consiste em levar o sistema todo ao limite de ruptura (stress) para medir a sua capacidade de recuperação quando a carga total diminui;
• Teste de Fumaça: consiste em um teste rápido, executando as principais funcionalidades do sistema, sem se preocupar com as condições de erro. O mesmo que teste do Caminho Feliz;
• Teste de Configuração: consiste em executar o sistema nas diversas configurações de hardware e software básico previstos para a sua execução em produção;
• Testes de Usabilidade: validam as condições de usabilidade do sistema, verificando mensagens emitidas para o usuário, clareza na comunicação do estado de execução da aplicação, navegação, dentre outras características, sempre sob a ótica do usuário;

Vou comentar os dois tipos menos conhecidos: smoke test e mock objects.

Mock objects ou Objetos Emulados, em português, são utilizados para descrever um caso especial de objetos que imitam objetos reais para teste, também atuam como Objetos Stub, fornecendo dados para o objeto em teste através dos objetos colaboradores. Por isso, eles também podem ser utilizados rotineiramente durante a criação dos cenários de teste.

Smoke test ou Testes de fumaça são verificações simples para busca de grandes erros, que geralmente afetam muitas funcionalidades e são fáceis de se detectar. Eles são geralmente executados antes de outras baterias de testes mais especializadas, pois, se grandes erros forem encontrados, provavelmente uma grande parcela dos outros cenários de verificações também irá falhar. Por isso, os testes de fumaça podem economizar tempo gasto com a execução de outras baterias de testes e com a identificação das causas dos problemas.

O nome deste tipo de teste deve-se aos testes de fumaça realizados em hardware. Se uma placa de hardware não pega fogo ou não solta fumaça durante um teste, então é um primeiro indício que a placa pode ter sido corretamente produzida. Esse termo também é utilizado em outras áreas do conhecimento, por exemplo, existem testes de fumaça para verificar a vedação de encanamentos e de instrumentos de sopro. É pressionado uma fumaça atóxica dentro dos objetos para verificar se existem rachaduras.

Testes de fumaça são geralmente pouco específicos e muito abrangentes, além de rápidos de implementar e de executar. Eles são úteis para capturar erros grandes, principalmente alguns erros de configuração e de ambiente que são facilmente detectados após a instalação do software.

http://www.teses.usp.br/teses/disponiveis/45/45134/tde-02042012-120707/publico/TestesAutomatizados_PauloCheque_Dissertacao.pdf

http://blog.caelum.com.br/facilitando-seus-testes-de-unidade-no-java-um-pouco-de-mockito/

✅Gabarito(D)

Mock objects são objetos com a mesma interface que os objetos externos usados para simular sua funcionalidade.

Fonte: Q386523