Menú

Burlarse de métodos privados, estáticos y vacíos usando Mockito

  • Principal
  • Otro
  • Burlarse de métodos privados, estáticos y vacíos usando Mockito

mocking private static

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Aprenda métodos falsos privados, estáticos y vacíos en Mockito con ejemplos:

En esta serie de prácticas Tutoriales sobre Mockito , echamos un vistazo al diferentes tipos de Mockito Matchers en el último tutorial.

En términos generales, los métodos privados y estáticos de burla entran en la categoría de burla inusual.

Si surge la necesidad de simular métodos / clases privados y estáticos, indica un código mal refactorizado y no es realmente un código comprobable y lo más probable es que algún código heredado que no se utilizó sea muy compatible con las pruebas unitarias.

Habiendo dicho eso, todavía existe soporte para Mocking de métodos privados y estáticos por algunos marcos de prueba unitarios como PowerMockito (y no directamente por Mockito).

Métodos privados, estáticos y vacíos de burlarse en Mockito

Los métodos 'vacíos' simulados son comunes, ya que puede haber métodos que esencialmente no devuelven nada, como actualizar una fila de la base de datos (considérelo como una operación PUT de un punto final de API Rest que acepta una entrada y no devuelve ninguna salida).

Mockito proporciona soporte completo para burlarse de métodos vacíos, que veremos con ejemplos en este artículo.

cuál es el mejor descargador de videos

Lo que vas a aprender:

Powermock - Una breve introduccion

Para Mockito, no hay soporte directo para simular métodos privados y estáticos. Para probar métodos privados, necesitará refactorizar el código para cambiar el acceso a protegido (o paquete) y tendrá que evitar métodos estáticos / finales.

Mockito, en mi opinión, intencionalmente no proporciona soporte para este tipo de simulacros, ya que el uso de este tipo de construcciones de código son olores de código y código mal diseñado.

Pero existen marcos que admiten la burla de métodos privados y estáticos.

Powermock extiende las capacidades de otros marcos como EasyMock y Mockito y proporciona la capacidad de simular métodos estáticos y privados.

# 1) Cómo: Powermock hace esto con la ayuda de la manipulación de código de bytes personalizado para admitir métodos privados y estáticos, clases finales, constructores, etc.

# 2) Paquetes compatibles: Powermock proporciona 2 API de extensión: una para Mockito y otra para easyMock. Por el bien de este artículo, vamos a escribir ejemplos con la extensión Mockito para poder simular.

# 3) Sintaxis :Powermockito tiene una sintaxis casi similar a Mockito, excepto algunos métodos adicionales para burlarse de métodos estáticos y privados.

# 4) Configuración de Powermockito

Para incluir la biblioteca Mockito en proyectos basados ​​en Gradle, a continuación se muestran las bibliotecas que se incluirán:

|_+_|

También hay disponibles dependencias similares para maven.

Powermock-api-mockito2 - Se requiere que la biblioteca incluya extensiones de Mockito para Powermockito.

Powermock-módulo-junit4 - Se requiere que el módulo incluya PowerMockRunner (que es un corredor personalizado que se utilizará para ejecutar pruebas con PowerMockito).

Un punto importante a tener en cuenta aquí es que PowerMock no es compatible con el ejecutor de pruebas Junit5. Por lo tanto, las pruebas deben escribirse en Junit4 y las pruebas deben ejecutarse con PowerMockRunner.

Para usar PowerMockRunner, la clase de prueba debe estar anotada con @RunWith (PowerMockRunner.class)

¡Ahora discutamos, burlándonos de los métodos privados, estáticos y nulos en detalle!

Burlarse de métodos privados

La burla de métodos privados, que se llaman internamente desde un método bajo prueba, puede ser inevitable en ciertos momentos. Usando powermockito, esto es posible y la verificación se realiza usando un nuevo método llamado 'verifyPrivate'

Echemos unEjemplo donde el método bajo prueba llama a un método privado (que devuelve un booleano). Para que este método devuelva verdadero / falso según la prueba, se debe configurar un código auxiliar en esta clase.

Para este ejemplo, la clase bajo prueba se crea como una instancia de espionaje con burlas en algunas invocaciones de interfaz e invocación de métodos privados.

Puntos importantes para el método privado simulado:

#1) El método de prueba o la clase de prueba debe anotarse con @ PrepareForTest (ClassUnderTest). Esta anotación le dice a powerMockito que prepare ciertas clases para las pruebas.

Estas serán principalmente aquellas clases que necesitan ser Bytecode manipulado . Por lo general, para las clases finales, las clases que contienen métodos privados y / o estáticos que deben simularse durante las pruebas.

Ejemplo:

|_+_|

#2) Para configurar stub en un método privado.

Sintaxis – when (instancia simulada o espía, 'privateMethodName'). thenReturn (// valor de retorno)

Ejemplo:

|_+_|

#3) Para verificar el método privado stubped.

Sintaxis - verifyPrivate (mockedInstance) .invoke ('privateMethodName')

Ejemplo:

|_+_|

Muestra de prueba completa: Continuando con el mismo ejemplo de los artículos anteriores, donde priceCalculator tiene algunas dependencias simuladas como itemService, userService, etc.

Hemos creado un nuevo método llamado - calculatePriceWithPrivateMethod, que llama a un método privado dentro de la misma clase y devuelve si el cliente es anónimo o no.

|_+_|

Burlarse de métodos estáticos

Los métodos estáticos se pueden burlar de una manera similar a como vimos para los métodos privados.

Cuando un método bajo prueba implica el uso de un método estático de la misma clase (o de una clase diferente), necesitaremos incluir esa clase en la anotación prepareForTest antes de la Prueba (o en la clase de prueba).

Puntos importantes para los métodos estáticos simulados:

#1) El método de prueba o la clase de prueba debe anotarse con @ PrepareForTest (ClassUnderTest). Similar a burlarse de métodos / clases privados, esto también es necesario para las clases estáticas.

#2) Un paso adicional que se requiere para los métodos estáticos es: mockStatic (// nombre de la clase estática)

Ejemplo:

|_+_|

#3) Para configurar stub en un método estático, es tan bueno como stubing cualquier método en cualquier otra instancia de interfaz / clase simulada.

Por ejemplo: Para stub getDiscountCategory () (que devuelve una enumeración DiscountCategory con valores PREMIUM & GENERAL) método estático de la clase DiscountCategoryFinder, simplemente stub como sigue:

|_+_|

#4) Para verificar la configuración simulada en el método final / estático, se puede utilizar el método verifyStatic ().

Ejemplo:

|_+_|

Burlarse de los métodos del vacío

Primero intentemos comprender qué tipo de casos de uso podrían involucrar métodos de anulación de código auxiliar:

#1) Llamadas a métodos, por ejemplo, que envía una notificación por correo electrónico durante el proceso.

Por ejemplo :Suponga que cambia su contraseña para su cuenta de banca por Internet, una vez que el cambio es exitoso, recibirá una notificación por correo electrónico.

Esto se puede considerar como / changePassword como una llamada POST a la API del banco que incluye una llamada al método void para enviar una notificación por correo electrónico al cliente.

#2) Otro ejemplo común de la llamada al método void son las solicitudes actualizadas a una base de datos que toman alguna entrada y no devuelven nada.

Los métodos de stubbing void (es decir, los métodos que no devuelven nada, o lanzan una excepción), se pueden manejar usando Funciones doNothing (), doThrow () y doAnswer (), doCallRealMethod () . Requiere que el stub se configure utilizando los métodos anteriores según las expectativas de la prueba.

Además, tenga en cuenta que todas las llamadas al método void se simulan de forma predeterminada en doNothing (). Por lo tanto, incluso si no se realiza una configuración simulada explícita en VACÍO llamadas a métodos, el comportamiento predeterminado sigue siendo doNothing ().

Veamos ejemplos de todas estas funciones:

Para todos los ejemplos, supongamos que hay una clase StudentScoreUpdates que tiene un metodo calculateSumAndStore(). Este método calcula la suma de puntuaciones (como entrada) y llama a vacío método updateScores () en la instancia de databaseImplementation.

|_+_|

Escribiremos pruebas unitarias para la llamada al método simulado con los siguientes ejemplos:

# 1) no hacer nada () - doNothing () es el comportamiento predeterminado para las llamadas al método void en Mockito, es decir, incluso si verifica una llamada en el método void (sin configurar explícitamente un void para doNothing (), la verificación aún será exitosa)

|_+_|

Otros usos junto con doNothing ()

a) Cuando se llama al método void varias veces y desea configurar diferentes respuestas para diferentes invocaciones, como - doNothing () para la primera invocación y lanzar una excepción en la siguiente invocación.

Por ejemplo :Configure un simulacro como este:

|_+_|

b) Cuando desee capturar los argumentos con los que se llamó al método void, se debe utilizar la funcionalidad ArgumentCaptor en Mockito. Esto proporciona una verificación adicional de los argumentos con los que se llamó al método.

Ejemplo con ArgumentCaptor:

|_+_|

# 2) doThrow ()– Esto es útil cuando simplemente desea lanzar una excepción cuando se invoca el método void desde el método bajo prueba.

Por ejemplo:

la puerta de enlace predeterminada no está disponible constantemente
|_+_|

# 3) doAnswer ()– doAnswer () simplemente proporciona una interfaz para hacer una lógica personalizada.

P.ej. Modificando algún valor a través de los argumentos pasados, devolviendo valores / datos personalizados que un código auxiliar normal no podría haber devuelto, especialmente para métodos vacíos.

Para fines de demostración: he eliminado el método void updateScores () para devolver un ' responder() ”E imprime el valor de uno de los argumentos que debería haberse pasado cuando se debería haber llamado al método.

Ejemplo de código:

|_+_|

# 4) doCallRealMethod ()– Los simulacros parciales son similares a los stubs (donde puede llamar a métodos reales para algunos de los métodos y eliminar el resto).

Para los métodos void, mockito proporciona una función especial llamada doCallRealMethod () que se puede usar cuando intentas configurar el simulacro. Lo que esto hará es llamar al método void real con los argumentos reales.

Por ejemplo:

|_+_|

consejos y trucos

# 1) Incluyendo múltiples clases estáticas en el mismo método / clase de prueba- Usando PowerMockito si hay una necesidad de simular varias clases estáticas o finales, entonces los nombres de las clases en @ PrepareForTest La anotación se puede mencionar como un valor separado por comas como una matriz (esencialmente acepta una matriz de los nombres de clase).

Ejemplo:

|_+_|

Como se muestra en el ejemplo anterior, suponga que tanto PriceCalculator como DiscountCategoryFinder son clases finales que deben burlarse. Ambos se pueden mencionar como una matriz de clases en la anotación PrepareForTest y se pueden apuntar en el método de prueba.

# 2) Posicionamiento del atributo PrepareForTest - El posicionamiento de este atributo es importante con respecto al tipo de pruebas que se incluyen en la clase Prueba.

Si todas las pruebas necesitan utilizar la misma clase final, entonces tiene sentido mencionar este atributo a nivel de clase de prueba, lo que simplemente significa que la clase preparada estará disponible para todos los métodos de prueba. A diferencia de esto, si la anotación se menciona en el método de prueba, estará disponible solo para esas pruebas en particular.

Conclusión

En este tutorial, discutimos varios enfoques para simular métodos estáticos, finales y nulos.

Aunque el uso de una gran cantidad de métodos estáticos o finales dificulta la capacidad de prueba, y aún así, hay soporte disponible para pruebas / simulaciones para ayudar a crear pruebas unitarias con el fin de lograr una mayor confianza en el código / aplicación incluso para el código heredado que generalmente no se usa para estar diseñado para poder ser probado.

Para los métodos estáticos y finales, Mockito no tiene un soporte listo para usar, pero bibliotecas como PowerMockito (que heredan en gran medida muchas cosas de Mockito) brindan dicho soporte y tienen que realizar la manipulación del código de bytes para admitir estas características.

Mockito listo para usar admite métodos de anulación de stubbing y proporciona varios métodos como doNothing, doAnswer, doThrow, doCallRealMethod, etc. y se puede utilizar según los requisitos de la prueba.

Las preguntas más frecuentes de la entrevista de Mockito se resumen en nuestro próximo tutorial.

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^