I recently decided to start writing User Interface tests for Tusker, my iOS app for Mastodon and Pleroma. But I couldn’t just write tests that interacted with an account on any real instance, as that would be far too unpredictable and mean my tests could have an impact on other people. The solution to this problem is, of course, mocking. The core idea is that instead of interacting with external things, your program interacts with mock versions of them, which appear to be their real counterparts, but don’t actually perform any of the operations they claim to. This allows for very tight control over what data the application receives, making it much more amenable to testing.

Unfortunately, if you search around, some of the most common solutions on the internet recommend using the environment variables (one of the only ways of sending data directly from the test to the application under test) to insert the mocked response into the app. Meaning, for every API response you need to mock, you would have an environment variable that contains the response data. This isn’t a great solution, because it leaves whole code paths untested (everything after the request URL would be generated). It would also mean that there’s no way of testing things like what requests are actually made by your app.

The solution to this problem is to actually run a local HTTP server that functions as the API server. This way, the app can communicate with the web server exactly as it would in the normal operating environment, but still have strictly controlled data. Of course, actually doing this isn’t quite so straightforward.