{"id":12508,"date":"2017-05-03T11:04:28","date_gmt":"2017-05-03T10:04:28","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12508"},"modified":"2020-07-30T12:57:58","modified_gmt":"2020-07-30T11:57:58","slug":"building-better-mock-servers-mobile-speakeasy","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/building-better-mock-servers-mobile-speakeasy\/","title":{"rendered":"Building better mock servers for mobile with Speakeasy"},"content":{"rendered":"

If you have a mobile app which communicates with a server through HTTP, then you (hopefully) have tests which ensure this communication works as expected.<\/p>\n

This usually involves providing canned responses in your tests, and doing this separately for iOS and Android. Pretty annoying, right? You\u2019re effectively duplicating work across multiple platforms, and the static nature of the responses make it difficult to test requests that cause data to be updated in the backend. Thankfully, there\u2019s a better way. At Intercom we\u2019ve improved on this by recreating our server logic in Go and embedding it into our iOS and Android apps.<\/p>\n

The old way ?<\/h2>\n

Previously we had two solutions for providing these server responses.<\/p>\n

Android<\/strong>: We had a mock HTTP client return static JSON which was defined in our test code. This suffered from the typical problem where backend data updates were hard to test. A test which required four new messages to be added to a conversation required five canned responses.<\/p>\n

iOS<\/strong>: We had a Node.js server which emulated our server logic, and we ran it locally on the same machine as the iOS simulator we were testing on. This allowed us to test the updating of data easily, but it meant that a testing environment required the ability to run external programs. This prevented us from using remote testing services like Firebase Test Lab and Xamarin Test Cloud.<\/p>\n

We had almost resigned ourselves to using the Node.js server on Android too, but we decided to investigate other options and discovered gomobile<\/a>, an experimental Go tool which makes it easy to use Go code inside Android and iOS apps. We decided to try using this to make our apps talk to a Go web server running on the same device.<\/p>\n

The new way ?<\/h2>\n

The first part of this was implementing our server logic in Go. This was actually much easier than a real backend implementation as we didn’t need to worry about scaling, persistence, etc. It just needed to return the same HTTP responses as our API did in production. We used Mux<\/a> to route the requests and relied on Go’s built-in JSON support to create and marshal our model objects. The common Speakeasy package defines a server that can take an Engine which decides how requests are handled.<\/p>\n


\nfunc (server *Server) Start() {
\nserver.Engine.Setup(server)
\nlog.Fatal(http.ListenAndServe(\":3000\", server.Router))
\n}
\nfunc (engine *SampleEngine) Setup(server *speakeasy.Server) {
\nhandler := engine.WrapHandler(engine.channelsResponse)
\nserver.Router.HandleFunc(\"\/channels\", handler).Methods(\"GET\")
\n}
\nfunc (engine *SampleEngine) channelsResponse(w http.ResponseWriter, r *http.Request) {
\njson.NewEncoder(w).Encode(ChannelsResponse{engine.AppState.ChannelNameList()})
\n}
\n<\/code><\/p>\n

The second part of this is embedding the server code in your app. You can do this using the Speakeasy tool which will generate an AAR file for Android and a framework for iOS. In our apps we distribute these through internal Maven and Cocoapods repos for easy integration and versioning. After including these in your app you can access your Go code through generated JNI methods in Android and C\/Objective-C methods in iOS.<\/p>\n


\n\/\/ SpeakeasyApplication.java
\nserverEngine = Backend.newEngine();
\nfinal Server speakeasyServer = Speakeasy.newServer(serverEngine);
\nThread serverThread = new Thread(new Runnable() {
\n@Override public void run() {
\nspeakeasyServer.start();
\n}
\n}, \"SpeakeasyServer\");
\nserverThread.start();
\n<\/code><\/p>\n

How this has helped us<\/h2>\n

We’ve seen a lot of benefits to using this:<\/p>\n