-
Notifications
You must be signed in to change notification settings - Fork 601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Body of request never makes it to stubRequestPassingTest: #52
Comments
Some code or a sample project maybe? More code, more info, etc? Logs are far from enough to help me debug this! What version of It seems strange anyway regarding your logs that the log says "Posting request 0xe1efbc0 with body:" letting us suspect an empty body, and that your assertion states that both the request body and the expected body are empty And finally it seems strange that you Unit test your request body (which is what you send, on which OHHTTPStubs does not have any control) instead of your response body (which is what OHHTTPStubs returns when you stubbed the request)? Anyway, more info is needed for me to help you on this. I'm not even sure that it is related to |
Thanks for the swift reply. I see the log was not complete, sorry about that. I got a new log here: 2014-02-06 16:08:33.293 xctest[73384:303] preparing response for /admin/_cmdstat.jsp Here is my test code:
Here is the production code:
Op 6 feb. 2014, om 14:46 heeft AliSoftware notifications@github.com het volgende geschreven:
|
I see you still check the uploaded/sent data, not the stubbed response. So this is probably related to this point "OHHTTPStubs don't simulate data upload" already explained in the README. |
It could be, but I don’t really want to simulate data upload, I want to check the data that would be posted/uploaded. Would you like me to create a minimum app with unit tests to show what is going on? |
Yes, or at least post the code of your test case, I can't see how I could help you without seeing a minimum piece of the code you are using. |
This should clear things up: https://bitbucket.org/jpalten/subbertesting |
I just tested your project. I commented your When iOS calls So I believe the issue you are experimenting is not related to If you put some symbolic breakpoints on Apple's I don't really understand why Apple does this, using the |
I encountered the same issue and I confirm that is an Apple's issue. A radar has been filled (http://openradar.appspot.com/15993891) feel free to dupe it. |
Thanks @lukabernardi Issue duped in my own I guess I can close this issue and mark it as an Apple Bug. |
In my test this is not happening with NSURLConnection (check out this test project http://cl.ly/TqlD) |
Damn you're right… and as if it wasn't strange enough, |
Yeah, the 3 times call drive me crazy. I take a look at the stack trace to be understand if it was a mistake of mine but it's seems that is only Apple that likes to mess with us ;) |
I actually had to wrap my tests with „alreadySeen” flags… I felt stupid doing it. Op 11 feb. 2014, om 22:02 heeft Luca Bernardi notifications@github.com het volgende geschreven:
|
Thanks for all the research and feedback. I’ll poke Apple about it. Jelle Op 7 feb. 2014, om 17:46 heeft AliSoftware notifications@github.com het volgende geschreven:
|
@lukabernardi Actually that's kinda strange that in your example with That's actually what made me refactor my API in version 2.0.0 and drove me crazy at that time in the beginning of the project too ;)
Now what's strange is that this is now not the case with |
Yep, probably it depends on the underlaying implementation. Do we want to speak about the fact that +[NSURLSession dataTaskWithURL:](and similar) are acting like a class cluster and is returning a private object that is not even a subclass o NSURLSessionTask et al.? |
;) That's probably related, as every Didn't investigate on what those private subclasses were / looked like, and neither tried and understand why they needed such a design pattern / architecture, but I'm afraid it's related to handle differently requests to internal and external protocols… I think I'll stop wondering and stop digging, I already went crazy long ago since version 1.0 with the multi-call to Cheers 🍻 |
Spoiler: the returned objects are all subclass of Cheers |
Given the probable toll-free-bridging needed/used to handle all this with |
Just to add some clarification. This happens only with NSURLSession. This is probably why Apple provides us access to currentRequest and originalRequest on NSURLSessionTasks objects. Seems like HTTPBody of originalRequest gets turned onto HTTPBodyStream on currentRequest. My solution to this was never checking on HTTPBody inside stubRequestsPassingTest:WithStubResponse: method, but instead provide a separate test, that specifically checks HTTPBody property on NSURLSessionTask originalRequest. |
I was previously using How would I go about doing this now that I can no longer inspect the XML-RPC payload in the |
Personally I'm using a terrible hacking and be aware that I'm definitely not endorsing this and I can do that only in a project where I'm in control of the code that is actually building the |
Interesting approach! I could probably just include the XML-RPC method as a header in a similar fashion as it is all that I am interested. Thanks for the idea! |
@lukabernardi @cwagdev Better approach would be never checking on HTTPBody in stubRequestsPassingTest: method, and provide a separate test, that creates NSURLSessionDataTask, and checks for originalRequest.HTTPBody. |
@DenHeadless I think what happened is that I effectively wrote integration tests. I am using OHHTTPStubs to return different XML responses based on the method being invoked. So it is effectively testing my client, xml creation, and xml parsing all together. Probably need to reduce this to actual unit tests instead. |
Guys, I got another workaround which seems cleaner than adding a dummy header and won't alter your requests:
I just confirmed that it works using @jpalten 's example project. For those who are using AFNetworking to build the request, one can provide a custom subclass of |
I just wrote a small Wiki Page with all the details about this workaround and some suggestion/example on how to implement it when using This would allow you to do stuff like this:
|
@AliSoftware that's definitely more cleaner solution. Thanks! |
👍 Thanks @AliSoftware ! |
Hi, not using OHHTTPStubs, but stumbled into this while hitting exactly this issue myself. Found your discussion very useful for diagnosing the problem. Boiled it down and produced a project demonstrating the problem at it's simplest (and the difference between NSURLSession and NSURLConnection) - https://github.com/samskiter/testnsurlprotocol Thanks for the information everyone and thanks @AliSoftware for the workaround |
@samskiter thx for the feedback 👍 |
Hi all, this issue should now have a workaround thanks to #166 (which has just been merged into master)! Will update the wiki entry and do a release soon. |
I use OHHTTPStubs to test if my AFHTTPRequest send the correct xml as body in a request. This works fine and all tests pass, checking the body that would be sent in the stubRequestPassingTest:
Now I moved to using AFHTTPSessionManager, and the program still works fine, but the tests fail, telling me that the body to be sent is empty, instead of the expected xml.
Something funny that happens: the request that gets prepared by my program has a different pointer (0xe1efbc0) than the request (0xe2c3310) that is checked in the stub. Any idea what is going on? Is it possible the requests gets copied, but the body didn't make it to the copy?
Here is a log from my console:
2014-02-06 14:09:36.278 xctest[69495:303] Posting request 0xe1efbc0 with body:
2014-02-06 14:09:36.278 xctest[69495:1903] Stubbing url /admin/_cmdstat.jsp
2014-02-06 14:09:36.278 xctest[69495:1903] checking body of request 0xe2c3310
2014-02-06 14:09:36.279 xctest[69495:1903] Would sent body:
/Volumes/InternalHD/Projecten/ZoneDirectorViewer/ZoneDirectorViewer/Connection/ServerConnectionTests.m:551: error: -[ServerConnectionTests testGetSystemInfo] : ((requestedBody) equal to (expectedBody)) failed: ("") is not equal to ("")
The text was updated successfully, but these errors were encountered: