By Andrew Daniel
As a mobile engineer, we’re often tasked with building features that require connecting to a backend API to fetch or post data. In this scenario, sometimes, you hear the phrase, “I can’t build that yet, the backend team hasn’t finished building the endpoint.”
Or maybe you’re not building a new feature, but modifying it instead, and for whatever reason, the backend’s down. This then leads to “I won’t be able to test it.” and “I’m blocked.”
Sometimes, there are things that really block you — this is true. Oftentimes however, there’s a way around it. The case of a backend endpoint is an example of the latter.
Good engineers always try to unblock themselves.
This post is an example of how the GO-LIFE iOS development team side-stepped a dependency on the backend team and continued development.
Beyond the obvious
Now, you might be thinking, “Hey, I could just use a mock server”, and you’d be right. However, most mock servers would just be a simple stub server (e.g. Apiary).
We wanted something better.
The GO-LIFE iOS team decided we wanted a solution that was more customisable and capable of complex processes and responses (e.g. returning different responses when hitting the same endpoint several times).
We used a specific configuration in Xcode to communicate with our mock server, which can return predefined responses for each endpoint according to what was agreed with the backend team beforehand (the API blueprint). The mock server itself was built using ExpressJs, which we can run locally on our machine through a simple one-line command in our terminal. Also, any person on the team can do this.
What the setup looks like
Creating an endpoint
Inside the mockserver directory, there’s an app.js file. In that, we first create an instance of Express
Right below that, we specify the endpoint we want to mock and return a JSON response with our mocked data. Here’s an example endpoint.
That’s all there really is to it! Just set the content type header to use application/json, include the JSON file you want to return (in our case we placed our JSON file in the folder called responses) and then just send that as the request response.
Finally, set up the mock server to listen on a certain port. In our case, we listened to port 3000, which means we can access the mocked endpoint at http://localhost:3000/foo.app.listen(3000, () => console.log('Mock Server running'));
We can test this by running the ‘node app.js’ command in the terminal.
Configuring the Xcode project
The iOS Go-Life Xcode project has several build configurations for Integration, Alpha, and Release. It’s here we add the plist files that have all the base URLs for our API. We added a configuration for our mock server and called it Debug.
Our project knows which configuration to use based on the script we added in the Build Phases tab of our project settings.
Finally, all that’s left to do is add a scheme that uses the Debug configuration. We created one called GoLife Mocked and switched to that scheme each time we want to use our mock server when developing a feature.
Some Added Benefits
In addition to using the mock server to develop features, you can also use it for UI testing. Since, we’re using something like Express, where we can have different responses based on request parameters or other control flows, we’re able to program some pretty complex testing scenarios.
That’s it! No more excuses about the backend. Happy developing! 🙌
In Indonesia, our customers depend on GO-LIFE for massages, makeovers, motor vehicle repairs and more. Besides fulfilling these needs, GO-LIFE also provides employment to 30,000 skilled workers, including many with impairments that would otherwise affect their chances of finding work. While we’re on the subject of work, did we mention that we’re hiring? Head over to gojek.jobs and come join us. 🤗