Grails Test con Spock: quale quadro di simulazione selezionare?

Question

Ho una domanda più generale. Quale framework o implementazione dovrei usare per il mocking in Grails 2.x quando si usa Spock?

Conosco un sacco di stile di derisione: utilizzo di Groove metaClass, Grails mockFor(), Groovy Mock(), stile di chiusura Groovy, ecc. Ognuno di essi ha i suoi vantaggi e svantaggi. Ma quello che non capisco è che in certe occasioni alcuni stili di derisione non sono in grado di determinare (ad esempio, mockFor() funziona per determinate implementazioni e non per gli altri).

Attualmente ho due implementazione simile del metodo di servizio mocking.

Questo funziona:

@TestFor(MyController) 
@Mock([MyDevice]) 
class MyControllerSpec extends ControllerSpec { 

void "test st."() { 
     def myService = mockFor(MyService) 
     myService.demand.myMethod() { def st -> 
     return "test" 
     } 
     controller.myService = myService.createMock() 
} 
} 

Tuttavia, questa implementazione non funziona:

@TestFor(MyController) 
@Mock([MyDevice]) 
class MyControllerSpec extends ControllerSpec { 

void "test st."() { 
     def yourService = mockFor(YourService) 
     yourService.demand.yourMethod() { def st -> 
     return "test" 
     } 
     controller.yourService = yourService.createMock() 
} 
} 

L'implementazione del servizio e chiamare dal regolatore è abbastanza simile. Quindi qual è la migliore pratica di derisione in Grails? O c'è qualche BUONA struttura di derisione per Grails che mi farebbe risparmiare tempo a capire come scherzare?

Grazie per qualsiasi consiglio! :-)

Mateo

Answer 1

Quando si utilizza quadro Spock per i test, quindi si cerca di sfruttare le opzioni e stili forniti dal framework stesso.

La struttura di Spock aiuta a raggiungere un BDD [Behavioral Design Development]. Per comportamento intendevo, puoi accoppiare strettamente lo scenario di accettazione aziendale al ciclo di sviluppo.

ho cercato di ottenere il vostro banco di prova scritta in Spock in quanto può essere riscritto come:

@TestFor(MyController) 
class MyControllerSpec extends ControllerSpec { 

    void "test service method in called once and only once"(){ 
     //Defines the behavior of setup 
     setup: "Only one invocation of service method" 
      def myService = Mock(MyService){ 
       //Make sure serviceMethod is called only once from the controller 
       //Beauty of Spock is that you can test the cardinality of 
       //method invocations. 
       1 * serviceMethod() >> "Hello" 
      } 
      controller.myService = myService 

      //The above process can be followed 
      //for stubbing/mocking 'YourService' and 
      //then injecting it to controller like 
      //controller.yourService = yourService 

     //Defines the behavior of action 
     when: "controller action is called" 
      controller.myAction() 

     //Defines the behavior of expected results 
     then: "Expect the stubbed service method output" 
      controller.response.contentAsString == "Hello" 
    } 
} 

//Controller 
def myAction() { 
    render myService.serviceMethod() 
} 

Se vedete sopra, si definisce il comportamento in ogni passaggio. Dal punto di vista aziendale, tali comportamenti saranno guidati da BA o dagli stakeholder. In questo modo, si conforma a ATDD/BDD (Deviazione Test Test Deviato/Test Driven Dev Test) e infine a TDD (Test Driven Dev) per il proprio progetto.

Per ulteriori dettagli su come utilizzare efficacemente il framework di spock, visitare il framework spock docs.