Page History

Resources

• httphttps://spockframework.org/spock/docs/12.3/index.html
• workshop 2 recording

Naming conventions

...

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: 'ROP 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

...

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. It is also a mater of personal choice this convention does not enforce either approach. . 

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 above we couldshould have used

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

...