These are chat archives for etorreborre/specs2

31st
May 2017
Jack Low
@wjlow
May 31 2017 00:58
I've got 2 test classes that I would like to share an embedded elasticsearch instance. This means spinning up an embedded elasticsearch before the 2 test classes run and then terminating elasticsearch after the 2 test classes have completed. From my understanding, BeforeAll and AfterAll inserts steps at the start and end of my test class. How could I insert a step at the beginning of 2 different test classes?
Eric Torreborre
@etorreborre
May 31 2017 07:46

@wjlow this is a typical set-up for which I don't have a great solution yet. Starting the instance is actually easy. Add a step at the beginning of each specification which will use a static method to start your instance. That static method can use a lazy val to make sure the instance is started just once. Now for stopping the instance one way is to use sbt to do the clean-up

testOptions in Test += Tests.Cleanup { loader =>
  loader.loadClass("org.mycompany.ShutdownElasticSearch").newInstance
}

object  ElasticSearch {
   lazy val instance = // start here
   def shutdown = instance.shutdown
}
class ShutdownElasticSearch {
    ElasticSearch.shutdown
}

A more elaborate solution consists in having a "parent" specification which has BeforeAfterAll steps and which references other specifications containing ElasticSearch code. So when you run this spec, there's only one start and one shutdown. There are 2 issues with this approach

  1. the parent spec needs to be updated each time there is a new ElasticSearch spec (but you can use the SpecificationFinder trait to find those for you)

  2. it is not possible to run those specifications independently so they need to be excluded from the sbt run. It is still possible to work around this for example by skipping them and have tags to run individual specs from the parent one, but again this is a more complex setup. Maybe I should try to see if I could encapsulate all of that into a reusable spec template because this is quite a common need if you don't go with the first approach

Fabio Labella
@SystemFw
May 31 2017 07:52
I've used the "more elaborate approach" successfully, by simply having the individual tests as traits that get mixed in the parent spec. Running them individually with tags also worked fairly painlessly, but I concluded that, given you typically need this set-up in integration/system test, is not worth the hassle and you can just run everything at once