Enhancement request: Overloading retrieveAsExpectations method with httpResponse as input parameter #58

Closed
rphgoossens opened this Issue Aug 7, 2014 · 10 comments

Projects

None yet

3 participants

@rphgoossens

Hi James,

I was wondering if it would be possible to overload the retrieveAsExpectations method so you can filter on the httpResponse as well.
I've the following scenario I want to test and without this enhancement I'm stuck right now:

  • set expectation for specific service with 1 reply
  • set expectation for the same specific service with 1 reply (different from the first)
  • start service chain (a bpm proces to be precise) which makes 2 service calls to said service and in this case with exactly the same request
  • retrieve and validate first expectation
  • retrieve and validate second expectation

Now the first retrieve expectation fails because I get 2 requests back, where I expected only one (the whole process is asynchronous and the second call has already taken place, the moment I run the check for the first call). If I could filter on the HttpResponse as well, I could distinguish between both service calls.

Regards, Roger.

@jamesbloomnektan
Collaborator

Yes that makes sense, I think I should be able to do this and release it in the next couple of days.

@jamesbloomnektan
Collaborator

When I looked more into the code I released the verify function is only used to know if the client has sent a request or not. Therefore it doesn't make sense to me why you would need to verify each call separately unless the request where different (and this is already supported).

Therefore can you not do the following:

  • set expectation for specific service with 1 reply
  • set expectation for the same specific service with 1 reply (different from the first)
  • start service chain (a bpm proces to be precise) which makes 2 service calls to said service and in this - case with exactly the same request
  • retrieve and validate two requests where sent
@rphgoossens

Hi James,
Thanks for the quick reply.
It's a bit difficult to explan, but i'll give it a try:
I have a very modular testcase (in soapUI) which I use to test different phases in the overall (flexible) bpm process (where each phase is actually a bpm process on it's own that may or may not take place).
The first phase is were the first service call takes place. If I test this phase seperately, only one service call is made which can be retrieved and validated. No problem here.
The third phase is where the second call to the service takes place. The testcase belonging to the third phase first calls the testcase belonging to the second phase which first calls the testcase belonging to the first phase.
Since the whole bpm proces is happening asynchronously in the background the moment I validate the first service call the second call may have already taken place and if so I get two requests where I expect only one.
If I have to do the (double) check at the end of my third testcase I have to remove the check in the first testcase and I lose a lot of modularity in my testsuite.

Regards, Roger.

@jamesdbloom
Owner

Ok that makes sense. I can add the functionality but at the moment I feel it would not make the API very clear or simple to use, but I'm happy to discuss it further.

The way I have resolved this sort of issue in the past is by:

  • first calling a function to determine the state of the system
  • then performing the action being tested
  • then checking the delta in the state of the system

For example:

  • first use Expectation[] retrieveAsExpectations(HttpRequest httpRequest) to retrieve the list of request & response for a given request
  • then perform the logic being tested
  • then check an additional request was added to the list

I have used Apache Commons Collections API for this. In particular the CollectionUtils.subtract function is helpful http://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/org/apache/commons/collections/CollectionUtils.html as it will return the delta between two lists.

@rphgoossens

Hi James,

I understand your concerns. It's a very specific usecase but I don't see any other way around it. The solution you provide won't help out either. Again when I check phase 3 the delta would show me 2 additional requests with no discernable difference between the two. The problem is caused by the asynchronicity of the flow and the way I want to modularize the testcases. I need a way to be able to make a distinction between both requests and since both requests are identical (they both retrieve some case data for a given case id), the only way I can think of to make the distinction, is by way of the httpResponse. So an additional Expectation[] retrieveAsExpectations(HttpRequest httpRequest, HttpResponse httpResponse) method would certainly help me out here.

Regards, Roger.

@jamesdbloom
Owner

Sorry for the delay but I've been flat out with two major initial releases of two new products.

I have implemented a solution for this with an extra verify method which should be exactly what you need. As soon as I have also fixed another small bug I will release both fixes together.

@jamesdbloom jamesdbloom added a commit that referenced this issue Aug 17, 2014
@jamesdbloom #60 fixed bug #58 added extension to support more flexible verificati…
…on - and added plugins for coverage and checkstyle however coverage restrictions are not yet set as some classes do not meet the required targets
d370329
@jamesdbloom
Owner

Closing bug as now fixed

@rphgoossens

Hi James, thanks for the hard work. Unfortunately I think there's still a piece of the puzzle missing in the solution. Could be my mistake for not clearing up the way I'm using mockserver right now for testing.
To retrieve the expectations I'm not using the java client. I make a REST call to the /retrieve resource provided by mockserver.
So what I would like mockserver to support is a retrieve with an httpResponse element in the JSON body.
Currently I can match on the httpRequest by for example sending the following JSON request:
{
"httpRequest" : {
"method" : "POST",
"path" : "/ThingyService/1.0",
"body" : {
"type" : "XPATH",
"value" : "//element='blabla'"
},
"headers" : [
{
"name": "Content-Type", "values": [".action="./jump".*"]
}
]
}
}

I would like to get an option to provide an additional httpResponse element for additional filtering like this for example:

{
"httpRequest" : {
"method" : "POST",
"path" : "/ThingyService/1.0",
"body" : {
"type" : "XPATH",
"value" : "//element='blabla'"
},
"headers" : [
{
"name": "Content-Type", "values": [".action="./jump".*"]
}
]
}
,
"httpResponse" : {
"body" : "...................."
}
}

Would it be possible to support this?

Regards, Roger.

@jamesbloomnektan
Collaborator

Hi Roger,

Can you use the HttpResponseMatcher or copy the code from the Java client into your application? What language are you using?

Thanks,

James

@rphgoossens

Hi James,

I'm not using any language really. I just make a HTTP REST call (PUT /retrieve) to the MockServer servlet with a body containing an httpRequest section followed by httpResponse section.
So I'm entering the MockServerServlet doPut operation (/retrieve in the switch). Somewhere down the line I'd like mockserver to support an additional httpResponse section for matching, as this section is currently ignored.

Regards, Roger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment