¿Cuáles son algunos consejos, trucos y errores al usar Spock para realizar pruebas?

Answer 1

• Use los bloques where separar los datos de prueba de la lógica de prueba incluso cuando no esté usando datos de prueba iterables.
• Mantener when bloques lo más cortos posible. La acción que se está probando debe ser enfocada y discreta. Con frecuencia veo numerosos pasos when todos, menos el último, deberían given .
• Utilice una expect después de un given pero antes de when verificar las condiciones previas.
• A veces, given…expect tiene más sentido gramaticalmente que when…then .
• Piense en la salida de diagnóstico generada por una aserción si falla. Por ejemplo, cars.engine.type.every { it == "V8" } producirá un diagnóstico mucho mejor que cars.every { it.engine.type == "V8" }
• Aprenda qué es un “tipo de valor”, identifíquelos en su sistema y nunca se burle de ellos ni los apague.
• Las simulaciones pueden duplicarse como talones, por lo que no es necesario utilizar afirmaciones de cardinalidad en cada llamada de método. Úsalos solo en los que te interesan en la prueba.
• Es probable que no necesite hacer valer la cardinalidad de la llamada y especificar un valor de retorno del método simulado.
• Si está confundido acerca de si utilizar un simulacro o un talón, piense en los apéndices como insumos: si hacen algo determinado, incitan el comportamiento que está probando, y simulacros como resultados, si el comportamiento que está probando funciona correctamente. resultados en un determinado evento.
• La gramática de Spock también es útil. Las interacciones de stub generalmente se especifican en interacciones given y simuladas en then . No tiene mucho sentido incluir afirmaciones de cardinalidad en el given .
• Algo que es un simulacro en una prueba podría tener sentido de ser un talón en otra.
• Use old(…) cuando necesite verificar que un valor cambia en términos relativos, pero no quiere codificar exactamente en qué cambia. Por ejemplo, verificando que un contador aumenta en n donde el valor anterior puede ser impredecible, expect: counter == old(counter) + 1 .
• Puedes usar cualquier cosa dentro de los valores old(…) no solo simples. Filas en una tabla en una prueba de Geb, por ejemplo.
• Afirmar basado en condiciones reales en lugar de datos de prueba. Por ejemplo, badGuys.every { it.alignment == "evil" } es mucho menos propenso a errores que badGuys*.name == ["Vader", "Palpatine", "Snoke"]
• Puede usar llamadas a métodos, consultas de bases de datos, contenido de archivos, cualquier cosa iterable, como fuente de datos para un bloque where . No tiene que ser una lista literal o tabla.
• spock-genesis es una buena biblioteca para pruebas basadas en propiedades.
• Nunca duerma en las pruebas: en su lugar, inyecte un reloj o un temporizador falso.
• Los igualadores de Hamcrest ocasionalmente pueden aclarar una afirmación. Por ejemplo, expect: that ingredients, containsInAnyOrder(["campari", "gin", "vermouth"]) ven mejor de lo expect: ingredients.toList().sort() == ["campari", "gin", "vermouth"]
• Spock with(Object, Closure) no es lo mismo que Groovy’s Object.with(Closure) : el primero hará afirmaciones, el último puede ser útil en bloques given .