Testy Grailsa ze Spockiem - Które szelki dobierają?

Question

Mam bardziej ogólne pytanie. Którego szkieletu lub implementacji powinienem użyć do wyśmiewania się w Grails 2.x podczas korzystania ze Spocka?

Znam ton szyderczy styl: dźwignia Groovy metaClass, Grails mockFor(), Groovy Mock(), Groovy styl zamknięcia, itp. Każdy z nich ma swoje zalety i wady. Ale nie rozumiem, że niektóre styl szyderczy działa w pewnych sytuacjach, których nie mogę określić (tzn. MockFor() działa dla pewnej implementacji, a nie dla innych).

Obecnie mam dwie podobne implementacje szyderstwa metody usługi.

Ten działa:

@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() 
} 
} 

Jednak ta implementacja nie działa:

@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() 
} 
} 

Realizacja usług i dzwoni z kontrolerem jest dość podobny. Więc jaka jest najlepsza praktyka kpienia z Grails? A może jest jakaś DOBRA szydercza struktura Grails, która zaoszczędziłaby mi czas na zastanawianie się, jak kpić?

Dzięki za porady! :-)

Mateo

Answer 1

Kiedy używasz ramy Spock do testowania, a następnie spróbuj wykorzystać opcje i style dostarczone przez samego ramy.

Spock ramy pomaga w osiągnięciu BDD [Behavioral Projekt Development]. Przez zachowanie, które miałem na myśli, można ściśle połączyć scenariusz akceptacji biznesowej z cyklem rozwoju.

starałem, aby uzyskać sprawdzian pisemny w Spocka, gdyż można ponownie zapisać jako:

@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() 
} 

Jeśli widzisz powyżej, określają zachowanie w każdym kroku. Z punktu widzenia przedsiębiorstwa te zachowania będą kierowane przez BA lub interesariuszy. W ten sposób postępujesz zgodnie z ATDD/BDD (Test oparty na akceptacji Driven Dev/Behaviour Test Driven Dev) i ostatecznie TDD (Test Driven Dev) dla twojego projektu.

Aby uzyskać więcej informacji o tym, jak skutecznie wykorzystywać ramy Spock, odwiedzić Spock ramy docs.