2011-03-06 6 views
5

Quiero probar que el controlador llama al método de servicio con los argumentos correctos. ¿Cuál es la mejor manera de hacer eso?Grails mockFor y cómo es mejor que probar El método se llama con argumentos correctos

Mi plan actual es usar mockFor y luego a través de la verificación de cierre el valor pasó. ¿Hay una mejor manera de hacer la prueba a través de mockito o el objeto burlado similar a lo que puedo hacer con mockito para realizar este mismo método llamada prueba valor argumento?

class HappyControllerTests extends ControllerUnitTestCase { 
     : 
    void testSomeValue() { 
     def mockControl = mockFor(HappyService) 
     def givenSomeItem = null 
     mockControl.demand.serviceMethod(1..99) { String someItem -> givenSomeItem = someItem; } 
     controller.happyService = mockControl.createMock() 

     controller.someAction() 

     mockControl.verify() 
     assertEquals("specific value", givenSomeItem) 
    } 
} 

Gracias!

+0

me gusta la respuesta de "Ted Naleid". Sin embargo, las grandes tiendas de mensajería instantánea deberían usar mockFor (..) Ver http://grails.org/doc/latest/guide/9.%20Testing.html#9.2 Pruebas de integración "... el uso de estos métodos garantiza que cualquier cambio que realice a las clases dadas no se filtran en otras pruebas ... " – finneycanhelp

Respuesta

13

rara vez utilizan mockFor ya que me parece maravilloso que está construida en MetaClass cosas y as ClassName a ser más fácil de trabajar y más potente, lo haría esto:

void testSomeValue() { 
    def givenSomeItem = null 
    controller.happyService = [ 
     serviceMethod: { String someItem -> givenSomeItem = someItem } 
    ] as HappyService 

    controller.someAction() 
    assertEquals "specific value", givenSomeItem 
} 
+1

Gracias por el ejemplo del código. Ese también fue mi punto de vista hasta que pasaron algunas cosas: 1) Fui a una gran presentación de Jeff Brown y hablé con él. 2) En la configuración de pruebas(), vi metaClass manipulado para todas las instancias de una clase a veces y no restaurado correctamente. Esto terminó causando un comportamiento de efecto secundario en todas las pruebas y yo fui el que buscó lo que estaba sucediendo. Así que ... Aunque es posible usar Groovy metaClass para objetos simulados que uno puede inyectar y simular Para los demás, recomiendo simplemente usar mockFor cuando en una gran tienda de Java. – finneycanhelp

+1

Normalmente, ataca el problema del que está hablando si cambia el metaClass en una clase. Si solo está modificando una instancia (como en el ejemplo anterior), casi siempre es seguro y los cambios solo vivirán mientras viva la instancia. La única vez que tuve un problema con esto fue cuando me burlé de una instancia de primavera inyectada que era un singleton. Esa misma instancia se había inyectado en otro lugar por lo que mis cambios no se descartaron después de la prueba. No estoy completamente en desacuerdo con usted en cuanto a la simulación, porque podría ser mejor en una gran tienda de Java, aunque la gente no esté muy familiarizada con el groovy. –

+0

Esto es realmente impresionante – tbruyelle

Cuestiones relacionadas