Forum Discussion

ejwoolley's avatar
ejwoolley
New Contributor
10 years ago

Need to use response elements from one mock operation in another mock operation

Hi, hopefully my terminology is not to incorrect, I'm fairly new to SoapUI and coding in general but I've been tasked with creating a mock service to aid in our testing.

 

The problem I have is  I have a dispatch script that takes elements from system generated request and puts them in a mock response, this is working.  However I have a 2nd mock operation which is a second stage of the service (1st is underwriting, 2nd verfication).  The request doesn't contain much info in the 2nd, so I need to grab data from the first mock operation request and use it to evaluate the response for the 2nd mock operation.  Unfortunately I can't work out how to do this (despite googling for several hours).  What I'm looking for is an easy to understand example to use for a REST mock service.

 

So I need to get firstname, surname from Underwriting mock operation and use those in Verfication mock operation.

 

Hopefully someone can point me in the right direction or post an example.  Thanks! 

  • rupert_anderson's avatar
    rupert_anderson
    Valued Contributor
    10 years ago

    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

    • rupert_anderson's avatar
      rupert_anderson
      Valued Contributor
      10 years ago

      Sorry, I also forgot to mention an even simpler way to persist the request data is just to store the data as individual properties in the mock's context variable and just use those to populate the second operations response. Whilst this is simpler, care needs to be taken if you want to test this with multiple requests, as the porpeties in the context would be shared and potentially overitten by simultaneous requests! If you just want to call the first operation, then the second in a single TestCase then it should be fine.

       

      Again can provide Groovy code snippets if you need more help getting started.

       

      Cheers,

      Rupert

    • ejwoolley's avatar
      ejwoolley
      New Contributor
      10 years ago

      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

       

       

      • rupert_anderson's avatar
        rupert_anderson
        Valued Contributor
        10 years ago

        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