Menú

Spock Mocking and Stubbing (ejemplos con tutoriales en video)

  • Principal
  • Otro
  • Spock Mocking and Stubbing (ejemplos con tutoriales en video)

spock mocking stubbing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Burlarse, golpear y espiar con Spock:

Pruebas parametrizadas en Spock Framework fue explicado en detalle en este Serie de tutoriales de formación sobre Spock .

Mocking y Stubbing son uno de los bloques de construcción más esenciales de las pruebas unitarias extensas. El soporte para burlarse y sustituir es como la guinda del pastel para un marco.

Para marcos existentes como JUnit, JBehave, etc., el soporte para simulacros y stubs no viene de fábrica, por lo tanto, requiere que un desarrollador use bibliotecas de terceros como Mockito, PowerMock, EasyMock, etc. para usarlos en el pruebas unitarias.

Burlarse, golpear y espiar

Para comprender simulacros y stubs y sus casos de uso, puede echar un vistazo a nuestra Serie de Mockito tutorial .

En este tutorial, aprenderemos más sobre las funciones incorporadas de Mocking y Stubbing integradas en la propia biblioteca de Spock, lo que a su vez permitiría usar la sintaxis Groovy más fácil y, por lo tanto, reduce la necesidad de agregar / incluir otros 3rdbibliotecas del partido.

Siempre puede incluir otros frameworks Mocking en sus pruebas, ya que todo el código Java válido también es código Groovy válido.

Lo que vas a aprender:

Aplicación bajo prueba

Primero definamos una aplicación Java de muestra, que probaremos usando simulacros y stubs en el marco de Spock.

Trabajaremos en una aplicación StudentGradeCalculator que toma el puntaje total de una base de datos resumida para una identificación de estudiante determinada y tiene una lógica simple de asignación de calificaciones dependiendo del valor del puntaje total. Usaremos una interfaz de base de datos que tiene pocos métodos para buscar y actualizar los puntajes y calificaciones de los estudiantes.

El código de la Aplicación estará disponible en la última sección de este tutorial.

Burlándose en Spock

Video Tutorial

En esta sección, veremos cómo instanciar e inicializar Mocks en el marco de Spock y cómo validar interacciones en el simulacro, es decir, la validación de las llamadas a los simulacros sucedió según las expectativas del método bajo prueba.

Con Mocks, no tiene que hacer muchas configuraciones, pero puede validar las interacciones que ocurrieron con los objetos simulados proporcionados a la aplicación bajo prueba.

Con simulacros, puedes hacer cosas como:

  • ¿Con qué argumentos fueron convocados los simulacros?
  • ¿Cuál fue el recuento total de invocaciones, etc.?
  • Determinar el orden de las simulaciones.

Veamos un ejemplo simple de StudentGradeCalculator, donde proporcionamos el objeto de implementación de la base de datos simulada y validamos las interacciones con la simulación. Intentaremos comprender las funciones de burla con ejemplos simples.

Tenga en cuenta que todas las validaciones de interacción deben realizarse en el bloque 'entonces' por convención.

A continuación se muestra el código del método bajo prueba. (que se llamará en el ' cuando: ' cuadra)

|_+_|

#1) Validación de las interacciones con argumentos exactos: primero validemos las interacciones con los argumentos exactamente esperados. Aquí esperaremos que los métodos simulados sean llamados con los argumentos exactos (según el flujo de ejecución del método).

Aquí ' estudiante ”Es el Mock de una interfaz de base de datos para la que estamos validando las interacciones.

|_+_|

Como se muestra arriba, estamos validando con los argumentos exactos, por lo que la implementación simulada debe haber sido llamada con. Cualquier cambio en estos argumentos hará que la prueba falle y el registro de errores muestre el motivo apropiado.

preguntas de la entrevista para desarrolladores de .net

Intentemos cambiar la calificación en ' updateStudentGrade ”A“ A ”en lugar de la llamada“ C ”y ver qué error obtenemos cuando se ejecuta la prueba.

|_+_|

Mostrará un error como 'Muy pocas invocaciones' ya que no puede encontrar la invocación Mock con los argumentos proporcionados.

#2) Ahora veamos cómo validar las interacciones simuladas sin proporcionar los valores reales de los argumentos, es decir, lo que nos interesa es saber que la simulación se invocó en el método pero no con qué argumentos.

Este tipo de requisitos son más comunes al escribir pruebas unitarias para el código de producción real, ya que no siempre es fácil identificar los argumentos reales que dependen esencialmente de la lógica comercial central de la aplicación bajo prueba.

La sintaxis es simple, solo necesita usar un guión bajo '_' para un argumento donde no se conoce el valor real.

Por ejemplo, para verificar cualquier valor de cadena, solo puede mencionar '_ como cuerda ”En lugar de un argumento en la prueba y debería pasar para cualquier valor de Cadena (de manera similar para otros tipos de datos primitivos y personalizados).

Entendamos esto con un ejemplo

|_+_|

Un punto importante a tener en cuenta aquí es que siempre puede mezclar y combinar los argumentos que se conocen y los que no se conocen. Por ejemplo, en el siguiente ejemplo, estamos validando la interacción de un simulacro con los argumentos reales y el otro con los matchers sueltos.

#3) Por último, veamos un escenario en el que podemos determinar el orden de invocación simulada, es decir, en qué orden se llamaron las simulaciones cuando se ejecuta la prueba.

A veces es esencial validar el flujo de eventos cuando hay múltiples colaboradores / simulacros involucrados en la aplicación bajo prueba y es útil comprender y validar que los métodos fueron llamados en una secuencia predeterminada.

|_+_|

Esto se puede lograr simplemente usando múltiples bloques 'entonces:' en el orden de las expectativas de secuencia simulada. Si la secuencia mencionada no cumplió con el orden real de invocación, se genera un error que detalla 'Orden de invocación incorrecto'.

Por ejemplo, si cambio el orden de lo anterior entonces declaraciones, la ejecución de la prueba arrojará un error como se muestra a continuación.

|_+_|

Stubbing en Spock

Video Tutorial

Exploramos todo sobre Mocking, ahora veamos cómo definir Stubs en los objetos simulados. Stubbing no es más que configurar respuestas predefinidas o predefinidas en las invocaciones simuladas para probar los diferentes flujos / escenarios de la aplicación bajo prueba.

Piense en ello como programar un simulacro para devolver un valor predefinido cuando fue llamado. Continuaremos con la misma aplicación StudentGradeCalculator y eliminaremos las llamadas de la interfaz de la base de datos para probar diferentes escenarios.

Un Stub es como un Mock que de alguna manera emula el comportamiento del objeto real. Simplemente puede llamarlo como un simulacro programado.

Sintaxis de stubbing

La sintaxis para apuntar es 2 operadores de desplazamiento a la derecha, es decir, ' >> ”

Para establecer un código auxiliar en cualquier llamada, puede definirlo de la siguiente manera:

|_+_|

Ahora comprendamos los diferentes escenarios de stubbing con ejemplos.

#1) Stubbing con parámetros reales: Si los argumentos se conocen de antemano o si desea establecer stub solo cuando la invocación es con argumentos especificados, se puede utilizar esta forma de especificar stubs.

|_+_|

Aquí, puede ver que el código auxiliar se ha configurado con un argumento exacto, es decir, StudentId en este caso como '123' (para cualquier otro valor, el código auxiliar no se invocará y se devolverá una respuesta predeterminada).

# 2) Stubbing con comparadores indulgentes: Si los argumentos no se conocen (o no son importantes), entonces podemos mencionarlos libremente como lo hicimos para los simulacros y la sintaxis sigue siendo la misma, es decir, el guión bajo '_'.

|_+_|

#3) Veamos otro ejemplo rápido en el que configuramos un código auxiliar para lanzar una excepción.

Estos escenarios son muy útiles para validar la lógica de manejo de errores de una aplicación bajo prueba (como en el mundo real, generar todas las excepciones en realidad no es posible, pero se podría configurar un simple stub para devolver cualquier excepción que queramos y luego afirmarla en el entonces bloque).

|_+_|

Espiar en Spock

Los espías se basan en objetos reales. es decir, necesitan la implementación de la interfaz y no la interfaz abstracta en sí. Los espías son poderosos y pueden permitirle obtener métodos reales llamados para la aplicación bajo prueba y verificar qué argumentos se solicitaron a los métodos.

Los espías también permiten definir simulaciones parciales en las instancias del objeto espiado. es decir, suponga que desea definir el comportamiento de algunos métodos en el objeto, luego puede y permitir que el resto se llame como llamadas de método reales.

Por lo general, son útiles en una situación en la que puede haber algunos métodos de interfaz que no están implementados y hay algunos otros que son completamente funcionales. Por lo tanto, usted, como desarrollador, puede optar por eliminar los no implementados y llamar a las implementaciones reales de los métodos funcionales.

Cabe señalar que, para los objetos Spied, a menos que se definan stubs, el comportamiento predeterminado será llamar a la implementación real. Dicho esto, no se debe llamar a los espías con frecuencia y toda la cobertura del escenario se puede lograr utilizando simulacros y talones y una combinación de ellos.

Veamos algunos ejemplos usando Spies en el marco de Spock usando el mismo ejemplo de EstudianteGradoCalculadora (Hemos creado una implementación real del StudentDatabase que es una implementación en memoria que usa HashMap para ilustrar la llamada a métodos reales y la devolución de datos. El código estará disponible en la última sección del tutorial):

# 1) Espiar usando una combinación de stub y llamadas a métodos reales

|_+_|

El ejemplo anterior ilustra la sintaxis para crear Spy usando el marco Spock. El stub se define en el momento de la declaración.

Además, las llamadas espiadas se pueden verificar como se ilustra en el bloque then (con comparadores de argumentos sueltos que se pueden definir para cualquier argumento específico).

# 2) Espiar usando todas las llamadas a métodos reales

|_+_|

En el ejemplo anterior, como no hemos mencionado ningún comportamiento stubped, todas las llamadas irán a la implementación real.

Conclusión

En este tutorial, aprendimos todo sobre las técnicas incorporadas a Mock Stub y Spy usando el marco de Spock. Spock lo hace fácil al combinar estas características como parte del marco en sí mismo con una sintaxis maravillosa más legible junto con el código repetitivo menor.

Los simulacros, los stubs y los espías se utilizan ampliamente en las pruebas unitarias para aumentar la cobertura y probar o validar la lógica empresarial central de la aplicación bajo prueba.

Código fuente de la aplicación

StudentReportGenerator.java: este es el método / aplicación bajo prueba

|_+_|

IStudentDatabase.java - Interfaz de base de datos

|_+_|

StudentDatabase.java: implementación de InMemory de la interfaz IStudentDatabase.java

|_+_|

En nuestro próximo tutorial, veremos cómo integrar el marco Spock con otros marcos y tecnologías de prueba.

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^