top 12 mockito interview questions
Preguntas más frecuentes de la entrevista de Mockito para descifrar la entrevista de Mockito:
En nuestro tutorial anterior, aprendimos Métodos privados, estáticos y vacíos de burlarse . Lea el tutoriales de formación completos en Mockito para una comprensión clara del marco Mockito.
Este artículo cubre las preguntas típicas de entrevistas más frecuentes en el marco Mockito Mocking.
Se espera que cada desarrollador o QA conozca los conceptos básicos de Mocking para escribir la mayoría de las pruebas de caja blanca (o pruebas unitarias) con facilidad y para burlarse de las dependencias para una cobertura de código mejorada y una mayor confianza en la aplicación.
Preguntas más populares de la entrevista de Mockito con respuestas detalladas
A continuación se enumeran las preguntas más frecuentes sobre los marcos simulados.
P # 1) ¿Por qué necesitamos burlarse?
Responder: Hay muchos casos de uso de burla que ayudan en la prueba unitaria del código bajo aislamiento y hacen que la prueba sea altamente repetible y predecible.
Generalmente se requiere burlarse cuando:
a) El componente bajo prueba tiene dependencias que aún no están implementadas o la implementación está en progreso.
Un buen ejemplo puede ser un punto final de la API REST que estará disponible más adelante en algún momento, pero lo ha consumido en el código a través de una dependencia.
Ahora que la implementación real aún no está disponible, la mayoría de las veces realmente sabe cuál es la respuesta esperada de esa API. Los simulacros le permiten probar ese tipo de integración.
b) El componente actualiza el estado del sistema.
Ejemplo: Llamadas a la base de datos: no querrá actualizar su base de datos con datos que son solo para fines de prueba. Esto podría resultar en la corrupción de los datos, además, la disponibilidad de DB es otro desafío cuando se ejecuta la prueba.
Por lo tanto, para evitar tal comportamiento, las llamadas a la base de datos podrían simularse en el componente bajo prueba. Por tanto, no hay un acoplamiento directo de DB y el componente bajo prueba.
Q # 2) Diferencia entre doReturn y thenReturn.
Responder: Mockito proporciona dos sintaxis diferentes para crear stubs como:
- doReturn y luegoReturn
- doNothing (no thenNothing)
- doThrow y luegoThrow
Ambos métodos configuran stubs y se pueden usar para crear / configurar stubs y, en ocasiones, se pueden usar indistintamente.
código de clasificación de inserción de c ++
Entonces, ¿en qué se diferencian ambos?
a) La forma thenReturn de stubbing es una forma segura de configurar stubs. Lo que esto significa esencialmente es que realiza una verificación en tiempo de compilación con los tipos de devolución que también desea apuntar.
Entendamos esto con un ejemplo:
Asume un método getItemDetails en mockedItemService que devuelve un objeto de tipo ItemSku. Así que con luego volver, no podrá devolver nada que no sea del tipo ItemSku, pero con doReturn, puede configurar el stub para devolver cualquier cosa y la prueba fallará (o lanzará una excepción) durante la ejecución.
// trabajos
|_+_|// lanza una excepción de tiempo de compilación
|_+_|// con doReturn, tanto la configuración del stub funciona como no es seguro para la compilación.
// aquí estamos intentando devolver un objeto de tipo double que todavía funciona y no arroja ninguna advertencia de tiempo de compilación.
|_+_|b) Otra diferencia importante entre estas 2 formas de stub es para los objetos simulados, aparte de la seguridad de compilación, no hay mucha diferencia.
Sin embargo, para los objetos Spied, el tipo de configuración de stub 'thenReturn' no funcionará, ya que resultará en llamar al método real antes de que la respuesta stubped se devuelva como la llamada y no en un Mock, sino en Spy, que está envolviendo una instancia de objeto real .
Así que supongamos que hay un espía llamado spiedObject y tiene un método testMethod que devuelve un número entero, luego, para configurar un código auxiliar en esto, deberá usar doReturn en lugar de thenReturn.
|_+_|P # 3) ¿Cuándo y por qué debería usarse un espía?
Responder: Spy es un tipo de simulacro parcial compatible con Mockito.
Esto esencialmente significa que es un tipo de instancia donde:
a) Cuando no se configura ningún simulacro, cualquier interacción con el espía resulta en llamar a los métodos reales. Pero aún le permite verificar las interacciones con el objeto espiado como si se llamó realmente a un método, cuántas veces se llamó al método, cuáles fueron los argumentos con los que se llamó al método, etc.
b) Te da la flexibilidad de configurar simulaciones parciales.
Por ejemplo, si tiene un objeto con 2 métodos: método1 y método2 y desea que se llame al método1 y que se burle del método2. Los espías proporcionan este tipo de configuración.
Por lo tanto, la diferencia entre un simulacro y un código auxiliar en términos simples es: una simulación se crea a partir de un tipo y no a partir de una instancia, mientras que un código auxiliar envuelve una instancia real del objeto de clase.
P # 4) ¿Por qué no se pueden burlar los métodos estáticos usando Mockito?
cambiar VPN Alemania
Responder: Los métodos estáticos están asociados con la clase en sí y no con una instancia particular de la clase. Esto significa que todas las instancias / objetos de la clase usan la misma instancia del método estático.
Los métodos estáticos se parecen más al código de procedimiento y se utilizan principalmente en sistemas heredados en general.
Las bibliotecas simuladas suelen crear simulacros mediante la creación de instancias dinámicas en tiempo de ejecución, ya sea a través de interfaces o mediante herencia y, como el método estático no está asociado con ninguna instancia en particular, no es posible que los marcos simulados (como mockito, easy mock, etc.) simulen métodos estáticos.
Los marcos como PowerMock, que tienen soporte para métodos estáticos, realizan la manipulación del código de bytes en tiempo de ejecución para simular métodos estáticos.
P # 5) ¿Cuál es la necesidad de verificar que se llamó al simulacro?
Responder: La configuración de un código auxiliar en un objeto simulado (o una instancia espiada) no garantiza si se invocó la configuración auxiliar.
Comparadores de 'verificación', brindan la posibilidad de validar si el código auxiliar que se configuró fue realmente invocado o no, cuántas veces se realizó la llamada, con qué argumentos se llamó al método cifrado, etc.
En esencia, nos permite verificar la configuración de la prueba y el resultado esperado de una manera más sólida.
P # 6) ¿Qué es un buen código comprobable?
Responder:
Algunos puntos sobre el código comprobable (lo que significa que podría probarse fácilmente por unidad) incluyen:
- Número reducido de dependencias o acoplamiento estrecho - Ejemplo: Las dependencias deben inyectarse en lugar de instanciarse directamente.
- Código que se adhiere a SRP (principio de responsabilidad única) - Esto esencialmente significa que la clase no debería tener múltiples razones para cambiar. La adherencia a SRP evita que las clases creen dependencia de sí mismo y mantiene el código cohesivo y limpio.
- Uso menor / mínimo de métodos estáticos y clases finales - Estos generalmente indican olores de código y se asociaron principalmente con el código heredado.
P # 7) ¿Cuáles son las limitaciones de Mockito?
Responder: Mockito es un marco de elección para la mayoría de los proyectos basados en Java. Es fácil de implementar, leer y comprender.
Algunos de los inconvenientes o limitaciones en cuanto a funcionalidad son:
- Su incapacidad para burlarse de los métodos estáticos.
- Los constructores, los métodos privados y las clases finales no se pueden burlar.
P # 8) ¿Qué frameworks pueden soportar métodos privados y estáticos de burla?
Responder: Los marcos como PowerMockito (extensiones del marco Mockito), JMockit, etc. proporcionan medios para simular métodos privados y estáticos.
P # 9) Mocking / Stubbing de métodos predeterminados en Interface en Java 8.
Responder: Con la implementación de Java 8 de los métodos predeterminados en Interface, Mockito proporciona soporte listo para usar para simular tales métodos predeterminados. (Tenga en cuenta que este soporte se introdujo a partir de Mockito 2 en adelante).
Estos métodos se pueden simular / eliminar como cualquier otro método de una clase o interfaz.
P # 10) ¿Cómo se puede verificar el orden de las invocaciones de stub en Mockito?
Responder: Cuando desee verificar el orden en el que se llamaron los simulacros, Mockito ' En orden ”Se puede utilizar la interfaz.
Durante la prueba, simplemente tiene que configurar / crear un objeto Inorder, enumerando una lista de objetos simulados en los que se debe determinar el orden de los simulacros (si hay varios métodos en el mismo simulacro y no hay otro simulacro que necesite para ser verificado, es suficiente mencionar la clase simulada solo una vez).
Considere la prueba dada a continuación que define un objeto de InOrder y menciona 2 ocurrencias de mockDatabaseImpl
|_+_|Además, como referencia, enumerar el código del método bajo prueba será útil para comprender el orden de ejecución de la prueba:
|_+_|Como se vio arriba, databaseImpl primero llama a updateScores y luego llama a getGrade.
Por lo tanto, si está escribiendo una prueba unitaria usando Mockito, para esto y necesita asegurar el orden de las llamadas en databaseImpl, consulte el código de prueba y asegúrese de que las afirmaciones se realicen según el orden esperado.
En el ejemplo anterior, si cambio el orden de las afirmaciones, la prueba fallará con una excepción de 'VerificationInOrderFailure'.
Después de cambiar el orden de afirmación, el código se ve como se muestra a continuación:
|_+_|La ejecución de prueba anterior arroja una excepción con el tipo:
'VerificationInOrderFailure' org.mockito.exceptions.verification.VerificationInOrderFailure:
Verificación en caso de fallo de pedido
Se busca pero no se invoca:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
P # 11) Devolver múltiples valores contra llamadas de método consecutivas
Responder: Para devolver diferentes valores para múltiples invocaciones del mismo método stubbed, Mockito proporciona 3 enfoques como se indica a continuación:
a) Usando separados por comas: Esto funciona con thenReturn.
Por ejemplo , tomando la muestra de código anterior, intentemos configurar un código auxiliar consecutivo para el método - getGrade que devolverá diferentes valores dependiendo de la secuencia de iteraciones:
|_+_|Esto significa que cuando los métodos getGrade son llamados en el método bajo prueba, la primera invocación devolverá 'A', la segunda invocación devolverá 'B' y así sucesivamente.
b) Posteriormente consecutiva: Este es un enfoque que está encadenado con las declaraciones de retorno. La aplicación de llamadas encadenadas al mismo ejemplo se verá como se muestra a continuación.
|_+_|c) DoReturn consecutivo: El último enfoque es usar doReturn en el formato encadenado como arriba.
|_+_|P # 12) ¿Cuáles son los diferentes tipos de frameworks de burla y cómo funcionan?
preguntas y respuestas de la entrevista del técnico de soporte de escritorio
Responder: Los tipos de framework Mocking y cómo funcionan se explican a continuación.
En general, existen 2 categorías de marcos de burla:
- Basado en proxy – Ejemplo, Mockito, EasyMock, etc.
- Basado en bytecode – Ejemplo, PowerMock, JMockit, etc.
Comparemos ambos marcos en diferentes parámetros.
| Basado en proxy | Basado en bytecode | |
|---|---|---|
| Simplícitamente | Más simple y fácil de usar | Puede implicar una compleja lógica de configuración simulada |
| Modo de creación | Se crea un proxy o un objeto falso que en realidad no requiere una instancia de clase / interfaz | Básicamente, implica la creación de objetos y, en tiempo de ejecución, manipula las instancias para el comportamiento simulado / stubbed |
| Funcionalidad | Burlarse de clases e interfaces | Además de clases e interfaces, permite burlarse de métodos estáticos, clases finales, etc. |
| Dependencia de Java | No muy estrechamente acoplado a las versiones de Java | Dado que estos marcos implican la manipulación del código de bytes, están estrechamente acoplados y es posible que no sean compatibles con versiones anteriores / posteriores de Java. |
| Ejemplos | Mockito, EasyMock etc. | PowerMock, JMockit, etc. |
Conclusión
El contenido cubierto en este artículo sirve para discusiones básicas sobre los marcos de simulación y específicamente la preparación de la entrevista de Mockito.
Además de obtener una comprensión teórica de las preguntas cubiertas, también se debe intentar hacer ejemplos de código real, lo que hace que el aprendizaje de estos marcos sea más divertido e interesante.
Espero que hayas disfrutado de toda la gama de tutoriales de esta serie de Mockito.
Feliz aprendizaje.
PREV Tutorial | PRIMER Tutorial
Lectura recomendada
- Preguntas y respuestas de la entrevista
- Tutorial de Mockito: Mockito Framework para simular en pruebas unitarias
- Algunas preguntas interesantes de la entrevista sobre pruebas de software
- Preguntas y respuestas de la entrevista de prueba ETL
- Principales preguntas de la entrevista sobre formularios e informes de Oracle
- Preguntas de la entrevista de prueba manual de software para profesionales experimentados
- Principales preguntas de la entrevista técnica de Oracle Apps y Oracle SOA
- Las 25 mejores preguntas y respuestas de la entrevista de pruebas ágiles