I am looking for a way to pass some result from one Actionword to another. And as I understand the current Hiptest-design this is not yet possible.
Use-Case: i would like to use Hiptest for end-to-end testing of a distributed service-landscape (no ui). The idea is to model commands for a service A with the usual parameter way. Since my command will trigger several other services (decoupled via event-messaging) I need to extract some identifier which was returned form the first service-call and pass this as a parameter to the next actionword which will assert that the following steps have occured.
Given CreateSomethingServiceA (name=A) => result would be id=1 Then ValidateServiceB (id=1) <= passed from previous actionword
My current understanding of Hiptest concludes that adding a simple return-value to actionwords wont work for several reasons
- actionwords can be composed freely by scenarios and other actionwords
- for Spock this gets even trickier because under certain conditions the generated Test uses an Expect-clause where actionwords must return a boolean-value.
- some more I guess
With the current design, I need to use more coarse-grained actionwords which, in my case, handle the validation as well. Modeling failure cases makes those actionwords even more complex because you need to add parameters which change the actionword-behaviour (e.g. skipValidation = true).
A workaround would be to use some shared state between all actionwords. The problem is, that shared mutable state can cause nasty sideeffects.
With this solution, you need to add technical “cleanup”-actionwords which also makes composition harder because it is easy to forget when you need to cleanup your state.
So, after giving this some though, how about using a shared state only within the generated test, so each test gets a new context-object.
This could be modelled in the hiptest-ui by setting a simple checkbox within a actionword meaning that this actionword makes use of shared state. Now the hiptest-publisher generates an additional parameter (a simple map with string->any probably suffices), for each actionword requiring it. Furthermore, the actual instance of the state is generated into the actual test reducing the side-effects to that test-execution.
With this in place, my use-case actionword-implementation would now set the id=1 within the shared state-instance, and the second actionword can read the id=1 from the state. I know this affects composition of actionwords but its a start.
What to you think? What other design considerations play a role here?