Simulacros, trozos y espías en el marco de Spock

Spock proporciona 3 herramientas poderosas (pero diferentes en esencia) que simplifican las pruebas de escritura: Mock, Stub y Spy.

Muy a menudo, el código que necesita ser probado necesita interactuar con módulos externos llamados dependencias (el artículo original usa el término colaboradores, que no es muy común en el entorno en ruso).

Las pruebas unitarias se diseñan con mayor frecuencia para probar una sola clase aislada utilizando varias variantes de mok: Mock, Stub y Spy. Por lo tanto, las pruebas serán más confiables y menos propensas a romperse a medida que evoluciona el código de dependencia.

Tales pruebas aisladas son menos propensas a problemas al cambiar los detalles internos de la implementación de dependencia.

De un traductor: cada vez que uso Spock Framework para escribir pruebas, siento que puedo cometer un error al elegir una forma de reemplazar las dependencias. Este artículo tiene la hoja de trucos más corta posible para elegir un mecanismo para crear mokas.

TL; DR

Simulacros

Use Mock para:

• verificaciones de contratos entre código de prueba y dependencias
• comprobar que los métodos de dependencia se llaman la cantidad correcta de veces
• validación de parámetros con los que se llama el código de dependencia

Trozos

Use Stub para:

• proporcionar resultados de llamadas predefinidos
• realizar acciones predefinidas esperadas de dependencias, como lanzar excepciones

Espías

Miedo espías. Como dice la documentación de Spock:

Piénselo dos veces antes de usar este mecanismo. Quizás debería rediseñar su solución y reorganizar su código.

Pero sucede que hay situaciones en las que tenemos que trabajar con código heredado. El código heredado puede ser difícil o incluso imposible de probar con mobs y trozos. En este caso, solo hay una solución: usar Spy.

Es mejor tener el código heredado cubierto con pruebas usando Spy que no tener pruebas heredadas.

Usa Spy para:

• prueba de código heredado que no puede ser probado por otros métodos
• comprobar que los métodos de dependencia se llaman la cantidad correcta de veces
• validación de parámetros pasados
• proporcionando una respuesta de dependencia predefinida
• realizar acciones predefinidas en respuesta a llamadas a métodos de dependencia

Simulacros

Todo el poder de moxas se manifiesta cuando la tarea de una prueba unitaria es verificar el contrato entre el código probado y las dependencias. Veamos el siguiente ejemplo, donde tenemos un controlador FooController que usa FooService como una dependencia, y pruebe esta funcionalidad con mobs.

FooController.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooController { FooService fooService def doSomething() { render fooService.doSomething("Sally") } } 

FooService.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooService { String doSomething(String name) { "Hi ${name}, FooService did something" } } 

En este escenario, queremos escribir una prueba que pruebe:

• contrato entre FooController y FooService
• FooService.doSomething(name) se llama la cantidad correcta de veces
• FooService.doSomething(name) con el parámetro correcto

Echa un vistazo a la prueba:

MockSpec.groovy

 package com.mycompany.myapp import grails.testing.web.controllers.ControllerUnitTest import spock.lang.Specification class MockSpec extends Specification implements ControllerUnitTest<FooController> { void "Mock FooService"() { given: "  " def fooService = Mock(FooService) and: "    " controller.fooService = fooService when: "  " controller.doSomething() then: "         " 1 * fooService.doSomething("Sally") and: "  ''    - 'null'" response.text == null.toString() } } 

La prueba anterior crea una simulación de servicio:

 def fooService = Mock(FooService) 

La prueba también comprueba que FooService.doSomething(name) se llama una vez, y el parámetro que se le pasa coincide con la cadena "Sally" .

 1 * fooService.doSomething("Sally") 

El código anterior resuelve 4 problemas importantes:

• crea simulacro para FooService
• verifica que FooService.doSomething(String name) se llame exactamente una vez con el parámetro String y el valor "Sally"
• aísla el código de prueba, reemplazando la implementación de dependencia

Trozos

¿El código probado utiliza dependencias? ¿El propósito de las pruebas es asegurar que el código bajo prueba funcione correctamente cuando interactúa con las dependencias? ¿Son los resultados de las llamadas a los métodos de dependencia valores de entrada para el código bajo prueba?

Si el comportamiento del código probado cambia según el comportamiento de las dependencias, entonces debe usar stubs (Stub).

Veamos el siguiente ejemplo con FooController y FooService y pruebe la funcionalidad del controlador usando stubs.

FooController.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooController { FooService fooService def doSomething() { render fooService.doSomething("Sally") } } 

FooService.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooService { String doSomething(String name) { "Hi ${name}, FooService did something" } } 

Código de prueba:

StubSpec.groovy

 package com.mycompany.myapp import grails.testing.web.controllers.ControllerUnitTest import spock.lang.Specification class StubSpec extends Specification implements ControllerUnitTest<FooController> { void "Stub FooService"() { given: "  " def fooService = Stub(FooService) { doSomething(_) >> "Stub did something" } and: "    " controller.fooService = fooService when: "  " controller.doSomething() then: "   " // 1 * fooService.doSomething() //        response.text == "Stub did something" } } 

Puede crear un trozo como este:

 def fooService = Stub(FooService) { doSomething(_) >> "Stub did something" } 

El código anterior resuelve 4 problemas importantes:

• crea un trozo de FooService
• se asegura de que FooService.doSomething(String name) devolverá la cadena "Stub did something" independientemente del parámetro pasado (por lo que utilizamos el carácter _ )
• aísla el código probado, reemplazando la implementación de dependencia con un trozo

Espías

Por favor no lea esta sección.

No mires

Salta al siguiente.

¿Todavía leyendo? Bueno entonces, está bien, tratemos con Spy.

No uses Spy. Como dice la documentación de Spock:

Piénselo dos veces antes de usar este mecanismo. Quizás debería rediseñar su solución y reorganizar su código.

En este caso, hay situaciones en las que tenemos que trabajar con código heredado. El código heredado no se puede probar con mobs o stubs. En este caso, el espía sigue siendo la única opción viable.

Los espías son diferentes de los mokas o trozos porque no funcionan como trozos.

Cuando una dependencia se reemplaza con un mok o stub, se crea un objeto de prueba y no se ejecuta el código fuente real de la dependencia.

El espía, por otro lado, ejecutará el código fuente principal de la dependencia para la cual se creó el espía, pero el espía le permitirá cambiar lo que devuelve el espía y verificar las llamadas a los métodos, al igual que los mokas y los trozos. (De ahí el nombre Spy).

Veamos el siguiente ejemplo de FooController , que usa FooService , y luego pruebe la funcionalidad con un espía.

FooController.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooController { FooService fooService def doSomething() { render fooService.doSomething("Sally") } } 

FooService.groovy

 package com.mycompany.myapp import groovy.transform.CompileStatic @CompileStatic class FooService { String doSomething(String name) { "Hi ${name}, FooService did something" } } 

Código de prueba:

SpySpec.groovy

 package com.mycompany.myapp import grails.testing.web.controllers.ControllerUnitTest import spock.lang.Specification class SpySpec extends Specification implements ControllerUnitTest<FooController> { void "Spy FooService"() { given: " -" def fooService = Spy(FooService) and: "   " controller.fooService = fooService when: "  " controller.doSomething() then: "     " 1 * fooService.doSomething("Sally") >> "A Spy can modify implementation" and: '     ' response.text == "A Spy can modify implementation" } } 

Crear una instancia de espía es bastante simple:

 def fooService = Spy(FooService) 

En el código anterior, el espía nos permite verificar la llamada a FooService.doSomething(name) , la cantidad de llamadas y los valores de los parámetros. Además, el espía cambia la implementación del método para devolver un valor diferente.

 1 * fooService.doSomething("Sally") >> "A Spy can modify implementation" 

El código anterior resuelve 4 problemas importantes:

• crea una instancia de espía para FooService
• comprueba la interacción de dependencia
• comprueba cómo funciona la aplicación de acuerdo con ciertos resultados de llamadas al método de dependencia
• aísla el código probado, reemplazando la implementación de dependencia con un trozo

FAQ

¿Qué opción usar: Mock, Stub o Spy?

Esta es una pregunta que enfrentan muchos desarrolladores. Estas preguntas frecuentes pueden ayudar si no está seguro de qué enfoque usar.

P: ¿El propósito de probar la verificación del contrato entre el código probado y las dependencias?

A: Si respondió Sí, use Mock

P: ¿El propósito de las pruebas es asegurarse de que el código que se prueba funciona correctamente cuando interactúa con las dependencias?

R: Si respondió Sí, use Stub

P: ¿Los resultados de llamar a los métodos de dependencia introducen valores para el código bajo prueba?

R: Si respondió Sí, use Stub

P: ¿Trabaja con código heredado, que es muy difícil de probar y no le quedan opciones?

A: Intenta usar Spy

Ejemplo de código

Puede encontrar el código para todos los ejemplos en este artículo en:

https://github.com/ddelponte/mock-stub-spy

Enlaces utiles

• http://spockframework.org/spock/docs/1.1/all_in_one.html#_interaction_based_testing
• https://martinfowler.com/bliki/UnitTest.html
• https://martinfowler.com/articles/mocksArentStubs.html