Page History

Resources

• https://spockframework.org/spock/docs/2.3/index.html
• workshop 2 recording

Naming conventions

• Specification classes are named as per the following:
  • Unit test specifications: <class_under_test>Spec
  • Integration test specification (using dependency instantiations or running containers): <class_under_test>IntegrationSpec

Use of Spock Blocks and Labels

1. The test 'def' should describe a high level scenario (not set up details or expected outcome)
   
   
2. Each label should have a description. The label plus description should form a readable English sentence preferring high level (Product Owner)
   type language over code level langue i.e. no method names etc.
   (since the label is the first word of the sentence the description should start with a lower case character and end with a full stop)
   Note. Well known acronyms should remain in uppercase as in normal (writing) language. e.g.  'the ROP period'
   
   
3. All blocks should be separated by a blank line except and 'and: ' block which really is a continuation of the previous block
   
   

4. Given-when-then v. expect. Given-when-then is the preferred format but expect block is useful in situations where it 'is more natural to describe
   stimulus and expected response in a single expression' see also the Spock Primer

   Code Block
   language groovy title Expect and Labels Example
   @Unroll def 'Celltrace scanner activation request with invalid ropPeriod value of #ropPeriod.'() { given: 'scanner details with an invalid rop period' eventHeaders = eventHeadersForCellTrace(ropPeriod, 'STREAMING') expect: 'the outbound request XML contains the default rop period of "FIFTEEN_MIN"' activateEventJobRequest.getRequest(eventHeaders).contains("<reportingPeriod>FIFTEEN_MIN</reportingPeriod>") where: 'ropROP period is any of these invalid values' ropPeriod << [ null, 0, -1, 123 ] }

   
   

5. Expected outputs in Spock data tables should be separated with a double pipe symbol (||) to visually set them apart

Use of assert keyword

The assert keyword is optional in 'expect:'  or 'then:' blocks. Groovy will automatically 'assert' any Boolean expression in these blocks.
Depending on the complexity of the expression and the amount of code in this block it might help to highlight what is being asserted using the 'assert' keyword. 

Current findings is that assertions are sometimes refactored into separate code blocks (methods or closures) and the DO NEED to use the assert keyword! But that often gets forgotten then and tets seems to pass but the assertions are no longer being checked and can lead to future false positives. To prevent this it is now recommended to always use the assert keyword.

In the example above we should have used

	expect: 'the outbound request XML contains the default rop period of "FIFTEEN_MIN"'
		assert activateEventJobRequest.getRequest(eventHeaders).contains("<reportingPeriod>FIFTEEN_MIN</reportingPeriod>")

Note. 'assert' is required in method or closures that arre called from these block if those methods contain Boolean expressions that need to be asserted!

Some more tips from the Spock Primer

...

1. Test duplication instead of using of data table or data pipes
   TBD: Create examples
   
   
2. Abuse of Spock tables; combining many tests (for different behavior) into one large table
   TBD: Create examples
   
   
3. JUnit legacy behavior : All conditions and expectations in the test name/scenario
   Instead of using the given-when-then label descriptions the developer puts all those in the scenario/test title.

Resources

...

1. .

...