Feature: Fake Responses

The idea is to create an environment variable or a launch argument which when set to true will use the fake responses if available.

This will remove the dependency of server while developing modules.

Fyi - I’d encourage leveraging this code base

OHHTTPStubs https://github.com/AliSoftware/OHHTTPStubs/blob/master/Examples/Swift/MainViewController.swift

I took this code one step further and allowed Charles saved traffic to replay with one line

https://github.com/johndpope/HAR-playback-swift

Thanks for sharing!

OHHTTPStubs are good but adding it as a dependency is something I would like to avoid. I am thinking more of a variable containing response as a string that will simulate the actual API on the basis of launch argument.

So it is more aligned to testing your views with the api contract before the actual api is created. I am not sure about the implementation right now and what all things to consider while implementing this functionality.

Thoughts?

I've seen this cruder approach with json string payloads from junior coders - when the end point api mutates - you end up with a bunch of rotten code. It also leaves a lot of case switching out to if test // load this string just creates a pile of poo. You can always fork OHHTTPStubs and simply rename it StubFire The crux of use case from my POV - boils down to enable stubbing intercept specified end points.

if url == "/getFriends" then load /parse using alamofire from a corresponding versioned json file with http status code 200. api changes / load a different one. disable stubbing.

Here's some code I crafted to load a response from swagger. https://gist.github.com/johndpope/009b9301ef422daca4c3588aad7b337b

https://github.com/AliSoftware/OHHTTPStubs/blob/master/Examples/Swift/MainViewController.swift

If you want to avoid third party dependencies - then by that rational you're also saying you want to not include Alamofire - which is crazy talk.

Thanks for sharing links. HAR-playback-swift looks very cool.

And nothing against using third party libraries but stubbing is a part of testing. Adding OHHTTPStubs as a dependency will force users to embed the framework inside their IPAs which they won't want to do. I will let users add them separately and create their own stubs.

you can target framework dependencies for different build configurations. eg. pod 'OHHTTPStubs' #, :configurations => ['Debug']

Thanks! Will investigate how can this be integrated with Carthage and SPM also.