Skip to content
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

Adds support for HTTPBody during testing when using NSURLSession #166

Merged
merged 1 commit into from
May 23, 2016

Conversation

felixLam
Copy link
Contributor

This addresses the issue described in https://github.com/AliSoftware/OHHTTPStubs/wiki/Testing-for-the-request-body-in-your-stubs and #52

It also avoids unnecessary changes to the code under test as the setter and getter for HTTPBody can still be used without change in behavior (as far as one can tell).

The new getter -[NSURLRequest OHHTTPStubs_HTTPBody] can be used in your [OHHTTPStubs stubRequestsPassingTest:withStubResponse:] to test the HTTPBody.

One known issue is that if you set the HTTPBody and later reset it to nil (for whatever reason),OHHTTPStubs_HTTPBody will still return the last non-nil value.

Thanks to @shagedorn for the help on method swizzling.

* by the time the request arrives to OHHTTPStubs, the HTTPBody of the NSURLRequest
* can't be accessed anymore.
*
* You can use this method to retrieve the HTTPBody for testing and
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for testing and...?

@AliSoftware
Copy link
Owner

Cool, looks interesting !

Don't forget to add an entry in the CHANGELOG to credit yourself.

I'm going on vacation for two weeks so I won't have time to check that PR until I return.

method_exchangeImplementations(originalMethod, swizzledMethod);
}

NSLog(@"Enabled method swizzeling setHTTPBody: on NSMutableURLRequest");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should probably remove the NSLogs now that you've debugged its proper integration?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was to make sure this never ends up in any code unnoticed. However, swizzling is used in other parts of OHHTTPStubs, too, and the framework should generally only be used for testing and the likes, so I agree, this can probably be removed.

@felixLam
Copy link
Contributor Author

Thanks for getting back so quickly! Enjoy your vacation, we will improve this PR in the meantime.

@shagedorn
Copy link
Collaborator

shagedorn commented Apr 5, 2016

If merged, you'd probably want to...

  • Adjust the Wiki entry
  • Post to issue #52
  • Adjust the version number in the changelog as appropriate

if (HTTPBody) {
[NSURLProtocol setProperty:HTTPBody forKey:OHHTTPStubs_HTTPBodyKey inRequest:self];
} else {
// unfortunately resetting does not work properly as the NSURLSession also uses this to reset the property
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If setting it to nil doesn't work, wouldn't it at least be an acceptable workaround to set it ton an empty NSData instead?

Copy link
Contributor Author

@felixLam felixLam May 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason we can't do that is that the session calls this method with nil which lead to the initial problem. If we touch the protocol property here we lose the benefit of this PR. The usual story is this:

  1. App sets up mutable request
  2. App sets body
  3. URL session for whatever reason resets it
  4. OHHTTP handles it

If we reset the property in step 3 again, we don't have access in step 4.

I believe that in production code it rarely happens that you set the body and then later need to reset it (at least missing support for this is the lesser bug, compared to not supporting the body IMHO). We can't really differentiate between the callers here unfortunately (to my runtime knowledge).

Copy link
Owner

@AliSoftware AliSoftware May 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, right.
Didn't understand your code comment at first (wrongly thought you meant "setting it to nil doesn't work"), but makes total sense now 👍

@AliSoftware
Copy link
Owner

AliSoftware commented May 11, 2016

Finally had time to check that PR 🎉 (sorry it took so long)

Please address the above comments, then rebase the branch on top of master — because as master has evolved since your PR, your branch is now in conflict (probably only because of the CHANGELOG entry, so not a complex conflict to fix 😉)

Otherwise I'm 👍

@AliSoftware
Copy link
Owner

  • Adjust the version number in the changelog as appropriate

FYI, in general I use a special ## Master entry for that (instead of the 5.x you created), so that we can add more and more entries and only specify what the exact version number it should be (according to semver) when releasing a new version only 😉

So when you'll be rebasing, you'll see that ## Master entry is now already existing on master (since I already merged other PRs that had it), so just put your changelog entry below the others of that section and I'll take care of changing ## Master to the proper version when I decide to do a release 😉

@AliSoftware
Copy link
Owner

AliSoftware commented May 21, 2016

Ping @felixLam ?

  • Remove OHHTTPStubsMethodSwizzling.h from the public headers in the podspec
  • Rebase

@shagedorn
Copy link
Collaborator

Sorry about the delay, we had a busy week and @felixLam was on holidays. We'll tackle it next week!

@AliSoftware
Copy link
Owner

np, thx

@felixLam
Copy link
Contributor Author

@AliSoftware I made the requested changes and rebased on master

@AliSoftware
Copy link
Owner

Thx 👍

(I don't know what's wrong with travis not reporting the test results on this PR suddenly… will investigate and merge once ok)

@felixLam
Copy link
Contributor Author

@AliSoftware there was a "minor" outage on GitHub today.

@AliSoftware AliSoftware merged commit 4874d3a into AliSoftware:master May 23, 2016
AliSoftware added a commit that referenced this pull request May 23, 2016
@AliSoftware
Copy link
Owner

@felixLam Ah good point that was probably it. Tested locally and force-merged onto master, (let wait for travis to check master now just to be sure… 😉)

@AliSoftware
Copy link
Owner

@felixLam In an effort to try and follow Moya's Contributor Guidelines, and to thank your for your recent contribution to OHHTTPStubs, I just added you as contributor to OHHTTPStubs so that you can now merge PRs and manage issues!
(Note: master is locked against direct commits, in order to force us to make PRs pass tests before we can merge any new code to master)

@shagedorn shagedorn deleted the feature/httpBodyAccess branch May 24, 2016 09:56
@felixLam
Copy link
Contributor Author

@AliSoftware Thank you very much. Credit where credit is due: @shagedorn did most of the heavy lifting here with the method swizzling.

@AliSoftware
Copy link
Owner

Right, added @shagedorn as a contributor as well just now 😉

@mikelupo
Copy link
Collaborator

mikelupo commented Jun 1, 2016

How should we #import the ability to utilize this new code? I can't seem to build it with just #include <OHHTTPStubs/OHHTTPStubs.h>

Note, I'm not using cocoapods to install. I'm dragging the xcodeproj into a frameworks group in my own xcode project. that's how I've always used OHHTTPStubs.

Thanks in advance

@felixLam
Copy link
Contributor Author

felixLam commented Jun 1, 2016

@mikelupo This PR should not require any changes on your end as far as I remember and should just magically work.

@mikelupo
Copy link
Collaborator

mikelupo commented Jun 1, 2016

Thanks for the quick reply.
Looks like its my problem. It's mainly because of the way that I integrate.
When I removed the existing OHHTTPStubs.xcodeproj from my workspace, it also removed references to it from my build phases where I was building/linking it into my bundle. So of course it would not find it.
:)

Now that I've resolved that, it still won't build unless I import:

#import <OHHTTPStubs/NSMutableURLRequest+HTTPBodyTesting.h>

In my test, I'm using the new method call like this:

NSData *myData = [request OHHTTPStubs_HTTPBody];

Mike

-----Original Message-----
From: Felix Lamouroux notifications@github.com
To: AliSoftware/OHHTTPStubs OHHTTPStubs@noreply.github.com
Cc: mikelupo mikelupo@aol.com; Mention mention@noreply.github.com
Sent: Wed, Jun 1, 2016 1:53 pm
Subject: Re: [AliSoftware/OHHTTPStubs] Adds support for HTTPBody during testing when using NSURLSession (#166)

@mikelupo The should not require any changes in your end as far as I remember and should just magically work.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@AliSoftware
Copy link
Owner

AliSoftware commented Jun 2, 2016

@felixLam @shagedorn while doing the 5.1.0 release, I just realized that maybe I merged that PR too quickly. I mean, it should work, but:

  • It's missing Unit Tests. We should add at least one unit test for this feature, ensuring that the code works and that there won't be any regression later
  • The file where you added the category is called NSMutableURLRequest+HTTPBodyTesting.h/m but is in fact an extension on NSURLRequest, not NSMutableURLRequest, so for consistency's sake we should probably rename it. Don't forget to update the name is the podspec as well.

That doesn't seem much work to do to make it right, so do you think you'd be able to throw a quick PR to add that soon, so I can include it properly in the upcoming 5.1.0 release?

Thx!

@felixLam
Copy link
Contributor Author

felixLam commented Jun 2, 2016

Absolutely. Will look at this tomorrow.

Am 02.06.2016 um 20:05 schrieb AliSoftware notifications@github.com:

@felixLam @shagedorn while doing the 5.1.0 release, I just realized that maybe I merged that PR too soon. I mean, it should work, but:

It's missing Unit Tests. We should add at least one unit test for this feature, ensuring that the code works and that there won't be any regression later
The file where you added the category is called NSMutableURLRequest+HTTPBodyTesting.h/m but is in fact an extension on NSURLRequest, not NSMutableURLRequest, so for consistency's sake we should probably rename it
That doesn't seem much work to do and make it right, do you think you'd be able to throw a quick PR to add that soon, so I can include it properly in the upcoming 5.1.0 release?

Thx!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@AliSoftware
Copy link
Owner

Cool Thx 👍

AliSoftware added a commit that referenced this pull request Jun 2, 2016
@AliSoftware
Copy link
Owner

ping @felixLam ?

@shagedorn
Copy link
Collaborator

@mikelupo the OHHTTPStubs.h file only includes the bare minimum of imports, which I assume is intentional ( @AliSoftware ?). To get everything, import OHHTTPStubsUmbrella.h, or use the modular import using @import OHHTTPStubs;, which will use the umbrella header.

I'm working on the remaining issues (rename & tests) right now and will submit a PR later today.

@AliSoftware
Copy link
Owner

the OHHTTPStubs.h file only includes the bare minimum of imports, which I assume is intentional

That's sadly a legacy issue, because when I created OHHTTPStubs years ago, I didn't think it would grow that much, and I only had one public class, named OHHTTPStubs, which have the same name as the pod/framework itself.

Now that OHHTTPStubs has grown a lot, OHHTTPStubs.h remains the header of only the OHHTTPStubs main class (like every other Foo class has its dedicated Foo.h header).
I can't use OHHTTPStubs.h itself as the umbrella header as well (because of cross-import reasons — I can't import every .h in OHHTTPStubs.h because some of those headers needs the OHHTTPStubs class to be defined first — and for subspecs reasons — especially, the headers we need to import depend on the subspecs people opt-in in their Podfile). I tried in some branches to improve that and make OHHTTPStubs.h the umbrella header but sadly it always led to complex problems and incompatibility with modular imports and all.

That's because of all these reasons that the umbrella header being OHHTTPStubsUmbrella.h and not OHHTTPStubs.h

But anyway, using the modular import @import OHHTTPStubs; is indeed the way to import modules nowadays, which thanks to the .modulemap I wrote automatically import the right umbrella header for you.


Looking fwd to your PR @shagedorn so that we can release the next version 👍

@felixLam
Copy link
Contributor Author

felixLam commented Jun 6, 2016

@AliSoftware Sorry for not following through with my promise on Friday. We had an unscheduled workload due to a rejection ;)

@shagedorn shagedorn mentioned this pull request Jun 6, 2016
@AliSoftware
Copy link
Owner

np I know those situations 😉

@AliSoftware AliSoftware mentioned this pull request Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants