¿Cuál es el propósito de Verificable () en Moq?

125

¿Para qué sirve Verifiable()?

Si verifico a Mocky dejo esto fuera, todavía verifica el SetUp.

Editar: Estaba usando VerifyAll()así la razón de que todo se verificara. Después de cambiar a Verify()solo mis .Verifiable() SetUps estaban siendo revisados.

moq

— Castrohenge
fuente

APÉNDICE: Como dice la otra respuesta, el propósito de .Verifiablees enlistar un Setupen un conjunto de " Verify(...)llamadas diferidas " que luego se pueden activar a través de mock.Verify().

La aclaración del OP deja en claro que este era el objetivo y el único problema era descubrir por qué no funcionaba, pero como lo señaló @Liam, la respuesta realmente debería tocar esto también: - Los casos de uso clave hasta donde puedo ver son:

el mantenimiento de sequedad entre una mock.Setup()ymock.Verify
lo que permite desconectar la configuración de una verificación de la Verifyllamada real (por ejemplo, puede configurarla en otro método auxiliar)

... y volviendo a mi respuesta, que de manera inequívoca dice "tenga cuidado, ya que los profesionales anteriores se consideran comúnmente compensados por el efecto que tiene el logro de esos objetivos en la legibilidad y la capacidad de mantenimiento de las pruebas que se apoyan demasiado en tales construcciones"

ORIGINAL: Tenga en cuenta que, cuando sea posible, uno debería seguir el diseño AAA y, por lo tanto, debería hacer mock.Verify( expression )llamadas explícitas después de que se haya realizado el trabajo, en lugar de mock.Setup( ... ).Verifiable()emparejarse con un mock.Verify()omock.VerifyAll() siempre que sea posible (crédito: @kzu ).

— Ruben Bartelink
fuente

@EricSmith Mirando hacia atrás, no creo que lo ponga con suficiente fuerza. Hay mucho más beneficio de dividir su trabajo en paquetes AAA que concentrarse demasiado en los puntos en común entre la fase de Arreglo y Afirmación. El 90% del tiempo, hay algo que se puede obtener de los matices de cómo expresa las llamadas de Verify al final, por lo que debería tomar mucho tiempo para optimizarlo, incluso si en algunos casos parece una duplicación dolorosa. Uno de los puntos que manning.com/osherove hace muy bien es que hacer que una prueba tenga sentido para alguien que salta es fundamental, ¡así que cumpla con la convención!

— Ruben Bartelink

Normalmente no soy de los que van en contra de la sabiduría aceptada, pero todavía no estoy convencido de los beneficios de AAA vs Verifyable()/ VerifyAll()en todos los casos. Mi prueba de unidad actual tiene una gran cantidad de Setup(...)llamadas (> 30). Podría hacer coincidir cada uno con un Verify () equivalente para satisfacer la convención, pero esto provoca una gran cantidad de duplicación de código y será más difícil de mantener y leer a medida que aumenta el número de pruebas unitarias. Supongo que lo que realmente pregunto es si se pueden hacer excepciones si hay una gran cantidad de configuraciones o si se evita Verifiable()una regla dura y rápida.

— Steve Chambers

@SteveChambers Un elemento clave de AAA es que no es A *: debe haber una sola Ley y una sola Afirmación. Entonces, si bien es técnicamente correcto al decir que es menos código para usted, las coincidencias de cuáles de sus configuraciones se aplican a qué (sub) actos y (sub) activos invariablemente se convertirán en un campo minado. Entonces, no, no es difícil y rápido, pero diría que sugerir que incluso está cerca de las 50:50 sería un muy mal consejo. (También tenga en cuenta que no necesita hacer una Configuración para hacer una Verificación a menos que esté tratando de introducir un comportamiento particular durante la Ley, que es otro elemento de pruebas claras)

— Ruben Bartelink

@Liam Y, de hecho, está muy bien que todavía estés convencido de que es una herramienta adecuada para tu trabajo; mi punto real es que está mal visto como un enfoque general para escribir pruebas con simulacros, es decir, a pesar del hecho de que logra perfectamente SECAR entre a Setupy a Verify, que puede estar perdiendo una ganancia más alta que se puede lograr solo relajando la restricción DRY de la manera sugerida por AAA y la familia de estrategias que implica fuertemente

— Ruben Bartelink

@Liam Gracias por la insistencia; Actualicé mi respuesta porque tienes razón en el punto que estás haciendo. En el pasado, cuando respondía preguntas SO como esta, mi opinión era en general exponer sucintamente una respuesta atómica y luego dejar que respuestas competitivas como la otra llenaran el mapa. En estos días (si todavía me tomé el tiempo para responder preguntas) probablemente trataría de dar la respuesta más completa que se ha convertido en primera instancia.

— Ruben Bartelink

Cuando Verify()se llama al método al final de la prueba, si alguna de las expectativas marcadas como verificables no se ha llamado, entonces es una excepción thrown.

VerifyAll() no verifica expectativas verificables.

— Suvesh Pratapa
fuente

¿le importaría explicar un poco más sobre VerifyAll () no verifica las expectativas verificables?

— JW

@JW Significa que VerifyAll verifica todas las configuraciones sin considerar si se han marcado como expectativas verificables.

— phoog