Package org.apache.tapestry5.spock

Class TapestrySpockExtension

  • All Implemented Interfaces:
    org.spockframework.runtime.extension.IGlobalExtension
    public class TapestrySpockExtension
extends org.spockframework.runtime.extension.AbstractGlobalExtension
    Facilitates Spock-based integration testing of Tapestry modules. Spock is a testing and specification framework for Java and Groovy applications. Supports injection of Tapestry services into Spock specifications.

    Usage example: 

     @ImportModule(UniverseModule)
 class UniverseSpec extends Specification {
 
   @Inject
   UniverseService service

   UniverseService copy = service

   def "service knows the answer to the universe"() {
     expect:
     copy == service        // injection occurred before 'copy' was initialized
     service.answer() == 42 // what else did you expect?!
   }
 }

    @ImportModule indicates which Tapestry module(s) should be started (and subsequently shut down). The deprecated @SubModule annotation is still supported for compatibility reasons.

    @Inject marks fields which should be injected with a Tapestry service or symbol. Related Tapestry annotations, such as @Service and @Symbol, are also supported.

    Note: Only field (and no constructor) injection is supported.

    To interact directly with the Tapestry registry, an injection point of type ObjectLocator may be defined. However, this should be rarely needed.

    For every specification annotated with @ImportModule or @SubModule, the Tapestry registry will be started up (and subsequently shut down) once. Because fields are injected before field initializers and the setup()/ setupSpec() methods are run, they can be safely accessed from these places.

    Fields marked as @Shared are injected once per specification; regular fields once per feature (iteration). However, this does not mean that each feature will receive a fresh service instance; rather, it is left to the Tapestry registry to control the lifecycle of a service. Most Tapestry services use the default "singleton" scope, which results in the same service instance being shared between all features.

    Features that require their own service instance(s) should be moved into separate specifications. To avoid code fragmentation and duplication, you might want to put multiple (micro-)specifications into the same source file, and factor out their commonalities into a base class.

    • Method Summary

      All Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      void visitSpec​(org.spockframework.runtime.model.SpecInfo spec)  

      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

      • Methods inherited from interface org.spockframework.runtime.extension.IGlobalExtension

        start, stop

    • Method Detail

      • visitSpec

        public void visitSpec​(org.spockframework.runtime.model.SpecInfo spec)