Knowledge Sharing: Groovy/Spock best practices refactoring

Knowledge Sharing: Groovy/Spock best practices refactoring

This commit shows many bad (before)/good (after) practises with Spock/Groovy Unit test like
- Mocking behavior and checking invocation (don't do both normally)
- When to use the word 'some' or 'my' for test variables/strings
- Remove scenarios that only apply to helper classes i.e. no branching in object under test
- Groovy 'magic' instead of java code
- Correct use of GString
- Update descriptions to refer to current (helper) classes an not old ones
- Use of assert keyword
- Consistent check of status code using 3pp constants
- Use 1 line when it is not too long (I don't mind up to 100-120 characters but it is just personal preference)
- Use Static imports where it does not reduce readability

Issue-ID: CPS-2922
Change-Id: If3a803ba3138193fdb75aa0236f9b9875e09ff6c
Signed-off-by: ToineSiebelink <toine.siebelink@est.tech>