A Brief rendezvous with Spock

This post is only such an honest attempt to share my short but effective experience with Spock. The testing class should extend “Specification” class which belongs to the spock.lang.* package. Lets, go through the structure of a Spock Specification class.

class SpockParameterized extends Specification{

  def numberA
  def numberB

Here the class SpockParameterized extends Specification . The Class Specification instructs JUnit to run the specification i.e. the test class with Spock’s JUnit runner, SPUTNIK. A Specification structure consists of the following components:

class SpockParameterized extends Specification{
//fields
//fixture methods
//feature methods
//helper methods
}

I will try to provide a little detailing on each of the above mentioned components.

FIELDS

Initializing objects into instance fields which may be used up in further proceedings (in feature methods) can be done here. One important thing to look out for is that, objects which are stored in instance fields are not shared among the feature methods, each feature methods gets their own copies, this thing makes the feature methods stateless and isolate them from each other. Now, if we want to make a field to be shared between feature methods, then we could use the annotation @Shared or use the keyword static. The static should always be used in case of constants.

FIXTURE METHODS

The Fixture Methods are like the lifecycle methods of Specification. There are four Fixture Methods. They are as follows:

def setupSpec()
{
}

This is similar to static methods annotated with @BeforeClass in JUnit.

def cleanupSpec()
{
}

This is similar to static methods annotated with @AfterClass in JUnit.

def setup()
{
}

This is similar to static methods annotated with @Before in JUnit.

def cleanup()
{
}

This is similar to static methods annotated with @After in JUnit. So the Fixture Method part is clear.

NEXT