Find Swift 2-compatible HTTP request mocking library about xcodeserversdk HOT 20 CLOSED

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

from xcodeserversdk.

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.

from xcodeserversdk.

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

from xcodeserversdk.

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

from xcodeserversdk.

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

from xcodeserversdk.

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.

from xcodeserversdk.

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

from xcodeserversdk.

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?

from xcodeserversdk.

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

from xcodeserversdk.

@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.

from xcodeserversdk.

@esttorhe Cool, reading the docs of Carthage atm.

from xcodeserversdk.

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

from xcodeserversdk.

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.

from xcodeserversdk.

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

from xcodeserversdk.

Ok, I did something in between: ad1e5e2. 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.

from xcodeserversdk.

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.

from xcodeserversdk.

👌 sounds good

from xcodeserversdk.

Ok, now we can actually start using it :)

from xcodeserversdk.

Bravo 👏 Hope that DVR will work for us!

from xcodeserversdk.

Puls, nice job with advertising XcodeServerSDK 👍

from xcodeserversdk.