Find Swift 2-compatible HTTP request mocking library

[czechboy0]

I'd like to add proper tests for requests/responses, so we need a library that helps us with that. I tried Mockingjay, unfortunately it doesn't yet have Swift 2 support. This is pretty urgent.

(cc: @cojoj and @esttorhe)

[esttorhe]

We could use OHHTTPStubs or VCR (can't remember the correct name; as soon as I remember I'll update it here)

[cojoj]

Well whet it comes to mocking I've recently read this cool article. But yes I agree that we need some solution to test this.

[esttorhe]

ahhhh; thanks @cojoj, DVR was the one I was thinking about; that's the one that Orta uses at Artsy; I wrote one called Rec but is not working correctly on Swift 2.0 and that's why I'm not suggesting that one :p

[cojoj]

Well, I've heard a lot of good about OHHTTPStubs but Objective-C - it hurts, lika a lot! 😜

[czechboy0]

I like the approach mentioned in the article. Let me take a :eyes:.

[esttorhe]

It's written in Obj-C but its compatible with Swift (more so if we use CocoaPods and just set the variable use_frameworks!).

You can see it in action on Ash Furrow's Moya.

The Demo uses OHHTTPStubs on its tests.

[czechboy0]

Ok, DVR isn't on Cocoapods, let me try with Carthage (this is my first time, be patient).

[cojoj]

I guess, that's the point when we have to get back to #5. There's no other way for us to handle mocking/stubbing without third-party, right?

[esttorhe]

@czechboy0 as long as its on a public Github and has a shared scheme its going to be available in Carthage

[czechboy0]

@cojoj This is exactly an example of where I much prefer to use a third party solution, instead of rolling my own. The recording approach is very simple and pretty much exactly how I was planning to do it manually anyway.

[czechboy0]

@esttorhe Cool, reading the docs of Carthage atm.

[czechboy0]

Carthage-related question: should I put the whole Carthage folder into gitignore? Or just the checkout? Or just the build? Or both?

[esttorhe]

TBH I've seen people checking in everything.

That depends on how you want to link. Some people use Carthage with update --no-build and only download the source and integrate the projects to their project inside a workspace (meaning you won't end up with Builds folder at all)

Or you could depend on Carthage to generate the frameworks and just add the generated package; which means that you'll have to keep the Builds folder on the repo.

[esttorhe]

Personally I just commit everything and depending on the project I use workspaces with the source code rather than the .frameworks

[czechboy0]

Ok, I did something in between: https://github.com/czechboy0/XcodeServerSDK/commit/ad1e5e2f172e197a5e3d379b58062b0faea94207. I went for the full manual approach, using Carthage to just pull the repo into its folder, but not build it. Then, I added the project as a subproject to XcodeServerSDK and added the appropriate dependencies for building and linking. But, since the code is not ours, I added the Checkouts folder to gitignore, so when this gets merged, you guys will need to run carthage update --no-build (which I also added to the README).

Let me know if this is a reasonable approach or not.

[czechboy0]

When it comes to this issue, thanks guys, I think I'll try DVR for now. I'll reopen if it doesn't work well.

[esttorhe]

:ok_hand: sounds good

[czechboy0]

Ok, now we can actually start using it :)

[cojoj]

Bravo 👏 Hope that DVR will work for us!

[cojoj]

Puls, nice job with advertising XcodeServerSDK 👍