I am pretty confused with the error "Unexpected method call" in PowerMock/EasyMock.
Let me know in which one of the below two scenario the above error refers to.
I have an written an expectation for a method and the method is not available in the actual code.
I have not written an expectation in junit for a method which is present in the actual code.
This means your mocked object received an unexpected method call (option 2 in your question).
To resolve this, you need to write an expectation that allows this invocation (or correct your application code if this method shouldn't be called).
Related
I am using Jmeter and I am testing if a JSON response from a GET request is correct by using JSR223 Assertion.
When the script is correct then the results are correct (unless of course there is something wrong with the response). However if the script is incorrect the test fails even though that the response is accurate, which is the expected behavior.
But then I have to check each line of the script so that I can find the differencies with the response in order to fix it. This wastes a lot of time.
I am not speaking of missing symbols but rather additional lines that are compared to the JSON response but are not actually in it. For example I am comparing country code in the assertion but there is no country code in the response.
Is there a way that JSR223 Assertion can return the differencies in the debugger for Jmeter?
Thank you in advance!
You have AssertionResult shorthand which is an instance of AssertionResult class therefore you can use the following methods:
AssertionResult.setFailure() - to indicate whether assertion successful or not
AssertionResult.setFailureMessage() - to set a custom message on assertion failure
Example code:
if (1 == 1) {
AssertionResult.setFailure(true);
AssertionResult.setFailureMessage("Expecteed something but it wasn't found");
}
Will produce output like:
More information on using JMeter Assertions: How to Use JMeter Assertions in Three Easy Steps
So we have a Web Api that for some 3rd party automation, the 3rd party will make a call to our API try Update some items.
Our Web Api will check if the items exists and some dependencies items (complex object in xaml/json) that need also be update before do the actual update process.
So the problem here is, if we found some dependencies that client haven't provided, I want to be able to response a Error Response message to the client with the exception and dependencies that need to be provided.
So the client can do a call to Api try update, if client got this error response with this error code and the content is these dependencies, the client can do automation with these dependencies.
Is it possible to do it?
Because I tried to use CreateErrorResponse, but it doesn't let me supply a content like CreateResponse(statusCode, complexObject)....
Or what is the best practice to work with this?
You're not limited to use CreateErrorResponse. It's just there to ease the job done by using already provided HttpError class:
http://msdn.microsoft.com/en-us/library/system.web.http.httperror%28v=vs.108%29.aspx
This class can contain additional set of key/value pairs that can be sent in response body.
However, you can always define your own error class (i.e. ApiError) that will contain exact data that you need, and then return that class by calling, i.e.:
Request.CreateResponse(HttpStatusCode.BadRequest, error);
Where error is instance of your ApiError class.
I have a filter that is filtering for some actions. In case this is a required action I need to render it and see its response (json). how could I invoke it and see if the response contains errors?
Thanks,
Have you tried the afterView?
afterView - Executed after view rendering. Takes an Exception as an
argument which will be non-null if an exception occurs during
processing. Note: this Closure is called before the layout is applied
More on the docs.
I'm using a Sinatra app to receive server requests and I want to dissect them in a separate class I call "request", but when I pass the request object the body gets dropped. Trying to read the request.body in the main class works but trying to read it in the new class generates a JSONparser octet error.
In the main Sinatra file, this test call generates the correct response:
puts JSON.parse request.body.read
after, I pass the request to the Request Class with the code below.
req=Request.new(request)
But in the Request class initialization def, the same "puts" code above generates the error:
JSON::ParserError - A JSON text must at least contain two octets!:
Both files include the JSON requirement.
A work around is fairly simple but I would prefer the more elegant solution if I could figure out why it is not working as I expect. Any thoughts are appreciated.
from my tests
the Request.new constructor doesn't seem to clone from Request object
request.clone works proper
you need to do the thorough object inspection if you need anything extreme
We are in the middle of a ongoing discussion about how to handle REST exceptions.
Response Content type : JSON
Two solutions we have:
Throw all the unchecked exceptions as a JSON response.
Send Request Invalid Response code.
Arguments:
When its a error, why return JSON? Just send a invalid response code.
Counter Argument:
Response code are too technical to handle for normal developers.
Whats your say??
For a JSON API I recently developed I do both. I always respond with valid JSON (well, assuming I respond at all). If I detect an invalid request, I use status 400. If I detect a server error (which I don't believe is caused by an invalid request), I use a 5xx status. The JSON object contains a special key that is only set for errors, with a string value.
I think this is a good solution that respects REST principles, and can be used in multiple ways. The same solution is used by some other JSON APIs, such as Yahoo Search. Try http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json .
Use error codes like for HTTP. So 50* for any exception cause by some internal problem. And 40* for bad arguments. Avoid using your own defined codes as far as its possible. The idea is to have a "uniform" interface.
In general.
204 for success without sending any content
200 for success with a json representation of the resource
And if its not a successful operation return appropriate response code. You can choose to optionally return a json. To simplify things you can have a common format (json) for all error responses.
http://en.wikipedia.org/wiki/REST is a must read before you freeze on your api specs.