Enable usage of Spring beans in @Shared fields, setupSpec() and cleanupSpec()

[leifhanack]

It would be absolutely great, if Spring's TestContext framework can be extended, so that Spring beans can be injected in @shared fields and can be used in setupSpec() and cleanupSpec().

Thanks, Leif

[xdhmoore]

+1 We are doing this on a project, and as a workaround setting fields in the setup() method. However, some of those fields we want to use in 'where' blocks, so we have a dummy feature at the beginning to initialize the fields so that the next feature has them when the 'where' block is run.

[leifhanack]

Could you give us a code example please?

[leifhanack]

Here is what we currently do as workaround:

@ContextConfiguration(classes = MyConfig, initializers = ConfigFileApplicationContextInitializer)
class MyRepositoryTest extends Specification {

  @Autowired
  CouchDbInstance myCouchDbInstance

  @Autowired
  ObjectMapperFactory objectMapperFactory

  MyRepository repository

  def myTempDbName = "mydb-" + new Date().format("yyyy-MM-dd-HH-mm-ss") + (new Random().nextInt(100) + 100)

  @Shared
  int testCount

  def setupDb() {
    if (testCount == 0) {
      repository = new MyRepository(myTempDb())
    }
    testCount++
  }

  def cleanupDb() {
    testCount--
    if (testCount == 0) {
      myCouchDbInstance.deleteDatabase(myTempDbName)
    }
  }

  CouchDbConnector myTempDb() {
    def db = new StdCouchDbConnector(myTempDbName, myCouchDbInstance, objectMapperFactory)
    db.createDatabaseIfNotExists()
    return db
  }

  def "should find entries where .."() {
    setup:
    setupDb()

    when:
    repository.add([someProp: "someVal", ..])

    then:
    repository.getMyFoo("FOO12").size() == ..

    cleanup:
    cleanupDb()
  }

[xdhmoore]

The following is a simplified version of what we are doing. My comment above refers to our "Dummy" feature below. If that feature isn't present, the createResourceDTO, updateResourceDTO, and testUserId are null in the "Call #path feature". The lack of Spring support in these contexts I think makes it more awkward to use spring-initialized variables in where blocks, because where blocks are run before setup blocks, if my understanding is correct. Our workaround has been to use static variables and initialize them in a setup() method, but also add a dummy feature so that the setup() method gets called before any real where blocks are hit. Let me know if any further clarification would be helpful.

@ContextConfiguration(
initializers = MyCustomApplicationContextInitializer.class,
classes = [ MyCustomTestConfig.class ]
)
@Stepwise
class SPCalendarSpec extends Specification {

   @Shared
   def static ResourceDTO createResourceDTO

   @Shared
   def static ResourceDTO updateResourceDTO

   @Shared
   def static String testUserId

   @Autowired
   public Environment environment

   @Shared
   def static String baseUrl

   def setupSpec() {

      /* 
       * Note: We cannot access Spring from this method, per this quote 
       * from the docs at https://code.google.com/p/spock/wiki/SpringExtension:
       * 
       * "Note: Due to the way Spring's TestContext framework is designed, 
       * @Shared fields cannot currently be injected. This also means that 
       * setupSpec() and cleanupSpec() cannot get access to Spring beans."
       */
   }

   def setup() {

      // Note: according to http://stackoverflow.com/questions/21149157/spock-all-shared-variables-are-null
      // the 'where' block of each feature is run before this method, so any 'where' blocks 
      // using these variables get the values from the invokation of the previous feature.

      baseUrl = buildLocalhostRootBaseURL();

      testUserId = environment.getProperty("ob.user.testUserId")

      createResourceDTO = new ResourceDTO()
      createResourceDTO.setUserId(Integer.parseInt(testUserId))
      createResourceDTO.setResourceName("CalendarName")
      createResourceDTO.setSvcId(1)

      updateResourceDTO = new ResourceDTO()
      updateResourceDTO.setUserId(Integer.parseInt(testUserId))
      updateResourceDTO.setResourceName("CalendarName2")
      updateResourceDTO.setSvcId(1)



      client = new RESTClient(baseUrl)
   }

   def RESTClient client


   def String buildLocalhostRootBaseURL() {
      return "http://" + environment.getProperty("tests.api.localhost") + ":" + environment.getProperty("tests.api.port") + environment.getProperty("tests.api.path") + "/"
   }

   // See comment at top of setup() method
   def "Dummy test to call setup() and populate the variables from Spring"() { }


   @Unroll
   def "#method - Call #path using http should produce successful return code"() {
      def response
      when: "rest call"
      if (method == "get" || method == "delete") {
         response = client."${method}"(
               path : path,
               contentType : "application/json"
               )
      } else {
         response = client."${method}"(
               path : path,
               contentType : "application/json",
               body : body
               )
      }

      then: "response 200/201"
      response.status == successStatus

      where:
      method   | body              | path                                | successStatus
      "put"    | createResourceDTO | "resource"                          | 201
      "get"    | null              | "resource/"+testUserId              | 200
      "post"   | updateResourceDTO | "resource"                          | 200
      "delete" | null              | "resource/"+testUserId              | 200
   }

[chrylis]

+1 for this feature. I have some Selenium tests that I'd like to convert to MockMvc tests, but I'm using @Stepwise to break out long interaction scripts into discrete methods, and this won't work with the new Spring HtmlUnit support.

[mallim]

+1 look forward for this feature

[leifhanack]

According to @sbrannen (see sbrannen/spring-test-junit5#1) the Spring Testing framework should be flexible enough so that this feature could be implemented by the Spock framework.

[ahansen1]

Not sure if it's helpful, but thought I'd share in case it was. We are currently using a TestExecutionListener and a base class to allow for having spring beans available in the setupSpec. It has been a while since I looked at it, but if I remember correctly we needed to "tickle" the applicaiton context to make sure Spring loaded it. Not using it for the @shared, so I am not sure if the same applies. Below is an example of the listener and the base class.

Base Class

@ContextConfiguration(locations = "classpath:applicationContext-test.xml")
@TestExecutionListeners(listeners = [SpringContextInitializingTestExecutionListener])
abstract class BaseSpecification extends Specification {
}

Listener

/**
 * A TestExecutionListener that tickles the Spring application context to ensure that it is initialized in the
 * beforeTestClass.  This allows us to have the application context initialize before the setupSpec.
 */
class SpringContextInitializingTestExecutionListener extends AbstractTestExecutionListener {
    @Override
    void beforeTestClass(TestContext testContext) throws Exception {
        testContext.applicationContext
    }
}

[leonard84]

There is a reason that it is explicitly forbidden to inject into @Shared fields, if you look at the org.springframework.test.context.support.DependencyInjectionTestExecutionListener which does the actual injection you can see that it only supports prepareTestInstance and beforeTestMethod which run in Spocks setup phase. Furthermore, if you are using org.springframework.test.annotation.DirtiesContext#AFTER_EACH_TEST_METHOD then the org.springframework.test.context.support.DirtiesContextTestExecutionListener will destroy the context after each test-iteration which could cause weird behaviour.
Another reason is that @Shared fields are - as the name suggests - shared between instances, this could also cause issues in multi-threaded executions. Another issue is that @Shared beans could be used in where blocks, however the injection happens to late for that.

One goal of spock is simplicity, but allowing @Shared injection is the opposite of that and for this reason it is disallowed.

[leifhanack]

Thanks @leonard84, so this issue can be closed? Or what thoughts do you have?

[xdhmoore]

As my example above indicates, when we were having trouble with this our biggest desire was to use Spring beans in where blocks which run before the setup phase, I think. Right now the only way we found seemed kindof hacky--Is there another solution to the example I posted above?

[BorzdeG]

+1

[jserranoTWS]

This workaround works for me:

@ContextConfiguration(classes = MyConfigClass.class)
class MySpec extends Specification {

    @Shared
    private InjectedObject obj;

    def cleanupSpec() {
        obj.deleteAllInBatch()
    }

    @Autowired
    void setInjectedObjectMethod(InjectedObject obj) {
        this.obj = obj
    }

}