unit testing - tipos - Spock: ¿se puede reemplazar una interacción definida en setup() en un caso de prueba?

qué es un escenario de prueba

Question

Estoy luchando para entender algo acerca de las interacciones de Spock en una prueba de unidad Groovy.

Tengo los siguientes tipos:

public interface Bar {
public String getMessage();
}
public class Foo {
private Bar bar;
public void setBar(Bar bar) {
this.bar = bar;
}
public String getMessage() {
return bar.getMessage();
}
}

y luego escribí la siguiente prueba Groovy / Spock:

class FooSpec extends Specification {
private Bar bar;
private Foo foo;
def setup() {
bar = Mock(Bar) { getMessage() >> "hello" }
foo = new Foo()
foo.bar = bar
}
def "say hello"() {
expect:
foo.message.equals("hello")
}
def "say goodbye"() {
setup:
bar.getMessage() >> "goodbye"
expect:
foo.message.equals("goodbye")
}
}

El código crea una instancia de Bar simulada en la configuración, inicializa Bar.getMessage() para devolver el hello y lo asigna a una nueva instancia de Foo .

La primera prueba verifica que foo.getMessage() es igual a hello .

La segunda prueba intenta modificar la bar simulada para que el método getMessage devuelva goodbye . Luego esperamos que foo.getMessage() (que delega a bar.getMessage() ) luego se devuelva goodbye . Sin embargo, la prueba falla como sigue:

FooSpec: decir adiós: 26 condición no satisfecha

porque foo.message sigue siendo igual a hello .

También probé lo siguiente:

def "say goodbye"() {
when:
bar.getMessage() >> "goodbye"
then:
foo.message.equals("goodbye")
}

y:

def "say goodbye"() {
when:
no_op()
then:
bar.getMessage() >> "goodbye"
foo.message.equals("goodbye")
}

Pero ambos fallaron con el mismo mensaje de saludo no es igual a un adiós .

Probablemente todavía estoy pensando en el modo Mockito, y asumo que una interacción es el equivalente de una expresión de when(...).thenReturn(...) , y que las interacciones posteriores anularían las interacciones anteriores.

¿Existe una forma sencilla de utilizar Spock para declarar una interacción en un método de setup y luego anular esa interacción en un caso de prueba? ¿O necesito eliminar el método setup() y básicamente agregar un bloque setup: a cada caso de prueba?

Answer 1

Esa es una trampa difícil. Como se indica en los docs , las interacciones declaradas en un bloque de entonces tienen prioridad sobre las interacciones declaradas anteriormente. Sin embargo, las interacciones declaradas en un bloque then tienen el alcance del bloque when anterior. (Esto permite tener múltiples pares cuando y luego.) Por lo tanto, su último intento no funciona, pero lo siguiente:

def setup() {
bar.message >> "hello"
}
def "say goodbye"() {
when:
def msg = foo.message
then:
bar.message >> "goodbye"
msg == "goodbye"
}

Estoy de acuerdo en que sería bueno que las interacciones declaradas en los métodos de prueba anulen siempre las interacciones declaradas en los métodos de configuración. De todos modos, una buena alternativa para anular las interacciones es que cada método de prueba llame a un método auxiliar que configura las interacciones esperadas para ese método de prueba.