top 12 mockito interview questions
Perguntas mais frequentes da entrevista Mockito para desvendar o Mockito Entrevista Mocking:
Em nosso tutorial anterior, aprendemos Métodos privados, estáticos e vazios de zombaria . Leia o tutoriais completos de treinamento no Mockito para uma compreensão clara da estrutura Mockito.
Este artigo cobre as perguntas mais comuns feitas em entrevistas típicas no framework Mockito Mocking.
Espera-se que cada desenvolvedor ou QA conheça os fundamentos de simulação para escrever a maioria dos testes de caixa branca (ou testes de unidade) com facilidade e simular as dependências para cobertura de código aprimorada e maior confiança no aplicativo.
Perguntas mais populares da entrevista Mockito com respostas detalhadas
Listadas abaixo estão as perguntas mais comuns sobre Mocking Frameworks.
P # 1) Por que precisamos de zombaria?
Responda: Existem muitos casos de uso de simulação que ajudam no teste de unidade do código em isolamento e tornam o teste altamente repetível e previsível.
A simulação é geralmente necessária quando:
para) O componente em teste possui dependências que ainda não foram implementadas ou a implementação está em andamento.
Um bom exemplo pode ser um endpoint da API REST que estará disponível posteriormente em algum momento, mas você o consumiu no código por meio de uma dependência.
Agora, como a implementação real ainda não está disponível, você realmente sabe na maioria das vezes qual é a resposta esperada dessa API. Mocks permitem que você teste esses tipos de integração.
b) O componente atualiza o estado no sistema.
Exemplo: Chamadas de banco de dados - você não gostaria de atualizar seu banco de dados com dados apenas para fins de teste. Isso pode resultar na corrupção dos dados, além disso, a disponibilidade do BD é outro desafio quando o teste é executado.
Portanto, para evitar esse comportamento, as chamadas de banco de dados podem ser simuladas no componente em teste. Portanto, não há acoplamento direto do DB e do componente em teste.
Q # 2) Diferença entre doReturn e thenReturn.
Responda: Mockito oferece duas sintaxes diferentes para a criação de stubs como:
- doReturn e depoisReturn
- não fazer nada (não então nada)
- doThrow e thenThrow
Ambos os métodos configuram stubs e podem ser usados para criar / configurar stubs e, às vezes, podem ser usados alternadamente.
algoritmo de classificação heap c ++
Então, como ambos diferem?
para) A maneira thenReturn de stub é uma forma segura de configurar stubs. O que isso significa essencialmente é que ele faz uma verificação em tempo de compilação em relação aos tipos de retorno que você também deseja criar stub.
Vamos entender isso com um exemplo:
Suponha um método getItemDetails sobre mockedItemService que retorna um objeto do tipo ItemSku. Então com então volte, você não poderá retornar nada além do tipo ItemSku, mas com doReturn, você pode configurar o stub para retornar qualquer coisa e o teste irá falhar (ou lançar uma exceção) durante a execução.
// funciona
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// lança exceção de tempo de compilação
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// com doReturn, a configuração do stub funciona porque não é segura para compilar.
// aqui estamos tentando retornar um objeto do tipo double que ainda funciona e não lança nenhum aviso de tempo de compilação.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) Outra diferença importante entre essas 2 formas de stub é para objetos Mocked, além da segurança de compilação, não há muita diferença.
No entanto, para objetos espiados, o tipo de configuração de stub “thenReturn” não funcionará, pois resultará na chamada do método real antes que a resposta em stub seja retornada como a chamada e não em um Mock, mas em Spy que está envolvendo uma instância de objeto real .
Então, suponha que haja um espião chamado spiedObject e tem um método testMethod que retorna um inteiro, então, para configurar um esboço nisso, você precisará usar doReturn em vez de thenReturn.
doReturn (10).when(spiedObject.testMethod());P # 3) Quando e por que um espião deve ser usado?
Responda: Spy é um tipo de mock parcial suportado pelo Mockito.
Isso significa essencialmente que é um tipo de instância onde:
para) Quando nenhum mock é configurado, qualquer interação no spy resulta na chamada dos métodos reais. Mas ainda permite que você verifique as interações com o objeto espiado como - um método foi realmente chamado, quantas vezes o método foi chamado, quais foram os argumentos usando os quais o método foi chamado etc.
b) Oferece flexibilidade para configurar simulações parciais.
Por exemplo, se você tem um objeto com 2 métodos - método1 e método2 e deseja que o método1 seja chamado e o método2 seja simulado. Os espiões fornecem esse tipo de configuração.
Portanto, a diferença entre um mock e um stub em termos simples é - um mock é criado a partir de um tipo e não de uma instância, enquanto um stub envolve uma instância real do objeto de classe.
P # 4) Por que métodos estáticos não podem ser simulados usando Mockito?
lista ligada circular c ++
Responda: Os métodos estáticos são associados à própria classe e não a qualquer instância particular da classe. Isso significa que todas as instâncias / objetos da classe usam a mesma instância do método estático.
Os métodos estáticos são mais parecidos com o código procedural e são usados principalmente em sistemas legados em geral.
Bibliotecas simuladas normalmente criam simulações por criação de instância dinâmica em tempo de execução, seja por meio de interfaces ou por herança e, como o método estático não está associado a nenhuma instância particular, não é possível simular estruturas (como mockito, easy mock, etc) para simular métodos estáticos.
Frameworks como o PowerMock, que têm suporte para métodos estáticos, executam a manipulação de bytecode em tempo de execução para simular métodos estáticos.
P # 5) Qual é a necessidade de verificar se a simulação foi chamada?
Responda: Configurar um stub em um objeto simulado (ou uma instância espiada) não garante se a configuração fragmentada foi sequer chamada.
Correspondentes de “verificação”, fornecem uma facilidade para validar se o stub que foi configurado foi realmente invocado ou não, quantas vezes a chamada foi feita, com quais argumentos o método stub foi chamado, etc.
Em essência, permite-nos verificar a configuração do teste e o resultado esperado de uma maneira mais robusta.
P # 6) O que é um bom código testável?
Responda:
Alguns pontos sobre o código testável (o que significa que pode ser facilmente testado na unidade) incluem:
- Número reduzido de dependências ou acoplamento forte - Exemplo: As dependências devem ser injetadas em vez de instanciadas diretamente.
- Código que segue SRP (Princípio de Responsabilidade Única) - Isso significa essencialmente que a classe não deve ter vários motivos para mudar. A adesão ao SRP evita que as classes criem dependência de si mesmas e mantém o código coeso e limpo.
- Menor / mínimo uso de métodos estáticos e classes finais - Geralmente indicam odores de código e estavam principalmente associados ao código legado.
Q # 7) Quais são as limitações do Mockito?
Responda: Mockito é um framework de escolha para a maioria dos projetos baseados em java. É fácil de implementar, ler e entender.
Algumas das desvantagens ou limitações em termos de funcionalidade são:
- Sua incapacidade de simular métodos estáticos.
- Construtores, métodos privados e classes finais não podem ser simulados.
P # 8) Quais frameworks podem suportar simulação de métodos privados e estáticos?
Responda: Frameworks como PowerMockito (extensões do framework Mockito), JMockit, etc. fornecem meios para simular métodos privados e estáticos.
P # 9) Métodos padrão de simulação / stub na interface em Java 8.
Responda: Com a implementação de métodos padrão do Java 8 na Interface, o Mockito fornece suporte pronto para usar para simular esses métodos padrão. (Observe que este suporte foi introduzido a partir do Mockito 2).
Esses métodos podem ser simulados / stubbed como quaisquer outros métodos de uma classe ou interface.
P # 10) Como a ordem das invocações de stub pode ser verificada no Mockito?
Responda: Quando você quiser verificar a ordem em que os mocks foram chamados, Mockito's “ Em ordem ”Interface pode ser usada.
Durante o teste, você simplesmente tem que configurar / criar um objeto Inorder, listando uma lista de objetos fictícios nos quais a ordem dos mocks precisa ser verificada (se houver vários métodos no mesmo mock e não houver outro mock que precise para ser verificado, é suficiente mencionar a classe simulada apenas uma vez).
Considere o teste fornecido abaixo, que define um objeto de InOrder e menciona 2 ocorrências de mockDatabaseImpl
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } Além disso, para referência, listar o código do método em teste será útil para entender a ordem de execução do teste:
public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); databaseImpl.getGrade(total); }Como visto acima, o databaseImpl primeiro chama updateScores e, em seguida, chama getGrade.
Então, se você está escrevendo um teste de unidade usando Mockito, para isso e você precisa garantir a ordem das chamadas no databaseImpl, consulte o código de teste e certifique-se de que as afirmações sejam feitas conforme o pedido esperado.
No exemplo acima, se eu alterar a ordem das afirmações, isso fará com que o teste falhe com uma exceção de “VerificationInOrderFailure”.
Depois de alterar o pedido de declaração, o código se parece com o mostrado abaixo:
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } A execução do teste acima lança uma exceção com o tipo:
desenvolvimento de software de exemplos de análise de causa raiz
“VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Verificação na falha do pedido
Desejado, mas não invocado:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
Q # 11) Retornando vários valores contra chamadas de método consecutivas
Responda: Para retornar valores diferentes para várias invocações do mesmo método stubbed, o Mockito fornece 3 abordagens conforme fornecido abaixo:
para) Usando separado por vírgulas: Isso funciona com o retorno.
Por exemplo , pegando o exemplo de código acima, vamos tentar configurar o stub consecutivo para o método - getGrade que retornará valores diferentes dependendo da sequência de iterações:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');Isso significa que quando os métodos getGrade são chamados no método em teste, a primeira chamada retornará “A”, a segunda chamada retornará “B” e assim por diante.
b) Consecutivo e depois Retorno: Esta é uma abordagem encadeada com as instruções de retorno. A aplicação de chamadas encadeadas ao mesmo exemplo terá a aparência mostrada abaixo.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) DoReturn consecutivo: A última abordagem é usar doReturn no formato encadeado como acima.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())P # 12) Quais são os diferentes tipos de frameworks de mocking e como eles funcionam?
Responda: Tipos de estrutura de simulação e como eles funcionam são explicados abaixo.
Existem basicamente 2 categorias de estruturas de simulação:
- Baseado em proxy - Exemplo, Mockito, EasyMock, etc.
- Baseado em bytecode - Exemplo, PowerMock, JMockit, etc.
Vamos comparar essas duas estruturas em parâmetros diferentes.
| Baseado em proxy | Baseado em bytecode | |
|---|---|---|
| Simplicitamente | Mais simples e fácil de usar | Pode envolver lógica de configuração simulada complexa |
| Modo de criação | Um proxy ou objeto falso que não requer realmente uma instância de classe / interface é criado | Basicamente, envolve a criação de objetos e, em tempo de execução, manipula as instâncias para o comportamento simulado / fragmentado |
| Funcionalidade | Classes e interfaces de simulação | Além de classes e interfaces, permite a simulação de métodos estáticos, classes finais etc. |
| Dependência de Java | Não muito estreitamente acoplado às versões java | Uma vez que essas estruturas envolvem manipulação de bytecode, elas são fortemente acopladas e podem não ser compatíveis com versões anteriores / posteriores nas versões Java. |
| Exemplos | Mockito, EasyMock etc. | PowerMock, JMockit etc. |
Conclusão
O conteúdo abordado neste artigo serve para discussões básicas em torno de estruturas de simulação e, especificamente, da preparação da entrevista de simulação.
Além de obter uma compreensão teórica das questões abordadas, deve-se também tentar fazer exemplos de código reais que tornam o aprendizado dessas estruturas mais divertido e interessante.
Espero que você tenha gostado de toda a gama de tutoriais nesta série Mockito.
Aprendizagem feliz.
PREV Tutorial | PRIMEIRO Tutorial
Leitura recomendada
- Perguntas e respostas da entrevista
- Tutorial Mockito: Framework Mockito para simulação em testes de unidade
- Algumas perguntas interessantes da entrevista de teste de software
- Perguntas e respostas da entrevista de teste de ETL
- Principais perguntas da entrevista sobre Oracle Forms e Reports
- Perguntas da entrevista de teste manual de software para profissionais experientes
- Principais perguntas técnicas da entrevista sobre Oracle Apps e Oracle SOA
- 25 melhores perguntas e respostas da entrevista para testes ágeis