Hi,
If I am understanding you correctly you have a situation like this:
Mock
-operation 1 (recieve details from request e.g. firstname & suranme)
-operation 2 (use those same details to populate the response)
Is this right?
If so, I would normally use Groovy scripts in the mock and a lightweight means of persisting the request data from operation 1 and retrievining it and using it to populate the response in operation 1. For this I have often used an in-memory H2 DB to persist the data. This approach is actually quite easy and doesn't take much code!
If you don't like the sounds of the lightweight DB, another mock Groovy script implementation might use a HashMap stored in the mock's context variable to persist the data. Actual quite similar in terms of code.
By the way, both of these approaches are covered in my SoapUI cookbook (sorry for blatant the self publicity! :-)) - but I would be more than happy to try to provide you with code snippets etc if you would like more help with either of the above approaches?
Hope this helps,
Rupert
Hi Rupert,
thanks for your response, to clarify what I'm doing in operation 1 (MockUnderwritingService) I'm getting the name and surname and some other stuff and customising the response based on the data, this gives a dynamic response based on user input and means for front end testing there is less changing of test stubs which are currently static...
so getting this sort of stuff;
de Firstname = recrods.Contact@FirstName.text();
def Surname = records.Contact.@LastName.text();
def ApplicationID = records.@ApplicationNumber.text();
then based on surname only decide whether to decline or accept, then I'm doing this to be able to use it in the response;
context.appID = ApplicationID
(not actaully returning the Firstname and Surname in the response but want to use these later)
then for operation 2 (VerificationMockService) dispatch script I want to do something like this;
if(Firstname == "John" && Surname == "Smith")
{
context.chan = channel
return "Accept"
}
else if (Firstname == "Dave" && Surname == "Smith")
{
context.chan = channel
return "Refer"
}
so it's working out how to use those variables Firstname & Surname in the second script that is the bit I'm having a problem with.
I'll do some reading up HashMap, might be what I'm looking for....can only be good if it expands my knowledge a bit further. Thanks for your help
Hi,
Ok, so it sounds like you are happy extracting the details you need from the request to the first operation.
But it sounds like you have separate mock services for each of the two operations e.g.
MockUnderwritingService.operation1
and
VerificationMockService.operation2
(not a single mock with two operations that need to shared the data, as I originally thought)
Is this the case? If so then the mocks need a shared place (that both mocks can access) to store the request details from operation1 so that operation2 can retrieve them. For this you could use a light-weight DB as mentioned before, or potentially store the data as properties on some other shared objects e.g. TestCase, TestSuite, Project (has potetntial concurrency risks mentioned previously).
For example if you use the HashMap, you would need to store it in a property stored against an object that both the mocks can see, not a particular mock's context, like I suggested before when I thought both operations were on the same mock service.
If this is the case and is helping then I can suggest more details.
Thanks,
Rupert
Thanks for your help, storing it as a property at project level seems to be the way forward. I'll look further into that and see if I can get something working to test it out.
No problem.
You can also set/get properties as SoapUI global properties e.g.
In your first mock set the name:
import com.eviware.soapui.SoapUI
SoapUI.globalProperties.setPropertyValue( "firstName", "john" )
and then in your second mock get the name:
import com.eviware.soapui.SoapUI
def firstName = SoapUI.globalProperties.getPropertyValue( "firstName")
Whilst this works and should do you, please beware the potential issues if you start calling the mocks from multiple threads / simultaneously.
Cheers,
Rup
