I'm verifying response of a grpc service method.
Right now im asserting response by taking out every parameter and verifying it against my expected test parameter.If there are many parameters to assert, it becomes a tedious process.
So im looking for something like 'Json comparator' which will verify my grpc response message with expected message .
I'm also thinking of converting my expected and my actual messages to json and verifying it using json comparator.But this is not straightforward.
So any other thoughts?
Protobuf messages override equals(), so you can hard-code the expected response message and use normal assertEquals(expected, actual) in JUnit.
Related
I have created a POST request to generate a token for myself. Next, I wrote the code for assertion using pm.test() and its working. Following that, I sent another request via pm.sendRequest(). As a result of this request, I am receiving a response but not able to assert it.
I should be able to assert a response if I am receiving one
. Any and all help is appreciated!
I am very new to Wiremock and even though I've went through the docs I still haven't wrapped my head around it completely.
What I'd like to find out is...
Is there a way to define in 1 stub two behaviours - a success response case and an error response (or multiple) case, in case e.g. the request's body-matching pattern was not satisfied?
Is that supported or I should write separate request matchers for every type of invalid e.g. request body? Of course in a bit more generalized fashion.
If it's possible to combine error response and success response in the same stub JSON could you, please give me an example or point me to one as well?
The specific example (e.g. the request's body-matching pattern was not satisfied?) can easily be accomplished using two different stubs with two different priorities.
The first stub would have a higher priority and be a more specific match and return the success response. The second stub would have a lower priority, essentially be a catchall for all other calls, and return the failure response.
For example, if the only difference was that you wanted all calls to "/success-endpoint" to return a 200, and any other ones to return the 400...
stubFor(get("/success-endpoint").atPriority(1)
.willReturn(ok("Success response body")));
stubFor(get(urlMatching("/.*")).atPriority(2)
.willReturn(aResponse().withStatus(400).withBody("Error response body")));
If you wanted to combine the success/error response in the same stub, you'd need to use a little more creativity. If the status code were in the request body, you could grab that using Response Template and plug it in as the response status code. If it weren't super visible and you needed to use something else in the request, you could create a Response Transformer and use that to inform your conditional response. Maybe Scenarios is something up your alley. Sorry that the rest of this response isn't super specific but instead sort of vague, but without knowing what your request/response looks like, there are a plethora of viable options.
I'm writing a microservice in Play. I'd like my controller to be able to generate client errors (4xx) with a particular JSON response body. However, Play's default HttpErrorHandler kicks in, and replaces my response body with an HTML document.
How can I have my response returned to the client untouched?
I have looked into providing a custom HttpErrorHandler, but this doesn't give access to the response that my controller had generated; the signature is:
def onClientError(request: RequestHeader, statusCode: Int, message: String): Future[Result]
Edit: I can no longer reproduce this problem. Now, the error handler doesn't kick in -- which is the behaviour I'd expect. Most likely some form of user confusion / error.
A client error is a condition which is caused by the client, and Play doesn't know how to handle. That includes malformed headers, non-existing resources (read : No route available for that path).
In all cases, this won't hit a controller : It's handled before it's routed. That also means there is no body that can be passed along.
If it does hit a controller, you're free to return a Result with the proper response code and body. If it doesn't hit a controller, and the error handler is invoked, you need to return a response based on the request itself.
An example of what you're trying to achieve would be handy, since it's a bi t unclear to me.
I am implementing a REST API and i have a set_ftp_credentials request
for example
POST api.domain.com/object/set_ftp_credentials
This request checks that the ftp credentials are good by trying to connect.
We had a discussion here whether we should return a HTTP response 200 and in the content
return the the request have failed and the reason.
Or we should return some other HTTP response code (40* response code).
What is considered the right way of doing this ?
And if not 200 then what do you think is the right response code ?
I believe that 200 is an OK response and should only be sent when the request was successfully satisfied.
One approach would be to answer the following questions for yourself:
What HTTP methods are you supporting?
What is the expected behavior of each HTTP method?
For each supported HTTP method, What are the possible classes of failures that can result if something goes wrong?
Now, return your expected response pay load with a 200 HTTP response code. Return client side error (400 class) or server side error (500 class) for the failures.
You might want to consider the following:
Return error codes that are specific to your application and map them to HTTP error codes
Have separate data contracts (assuming JSON format or XML schema) defined for successful response and error responses
not really sure where to start here other then to dive into CF (I REALLY don't want to do that) but....
I have an NSURLConnection signing OAuth2 requests to an ASP.NET WebAPI Resource Server, this resource server returns JSON body AND statusCode 400. I have yet to find a way to parse the data from the response when it returns code 400.
Does anyone here have any ideas? I would prefer to keep using NSURLConnection as this is only an OAuth2 consumer class. My other code is using restkit, but I do not want the OAuth2 end to require said library.
The process to parse data from a request which returns status 400 should be identical to that of a request returning status 200.
Simply note the status code in -connection:didReceiveResponse: and allow the request to continue; you will receive any additional data that the server sends in -connection:didReceiveData: as usual. Finally, you'll get a -connectionDidFinishLoading: call when all data has been received, and you can parse the JSON there.
Does your HTTP request Accept header specify "application/json"? If so, then this is probably an IIS bug and not iOS.
Interestingly enough, MVC4 ActionResult is broken in the RTM. Switching it over to Pure WebApi and fine tuning the response, I was able to finesse it into returning the proper data, it was likely serializing the json improperly which other languages weren't catching.