At Badoo, we use Calabash for automated Android application testing. One of our goal is to make it super easy for developers to run these tests in one command without going through the pain of setting up a test-scripting environment (Installing JDK, Android SDK, Ruby, and praying that nothing else has been added since the documentation was written). The two obvious choices were Vagrant and Docker. Speed of execution was one of the main criteria for us, so we ended up choosing Docker.
Most of the people in our team use Mac laptops and setting up Docker with Calabash-Android on Mac is not straightforward. In this article I will share with you the problems we had and the solutions we implemented.
Docker for Mac is built on top of xhyve, one of the derivatives of the OS X Hypervisor.Framework, but it does not support USB. This is immediately a problem, because the Android Debug Bridge (ADB) needs the USB system to detect and communicate with phones.
Running ADB starts a server which manages the Android devices, but that server normally runs on the same machine. Instead, we start the ADB server on the Mac (which can see the USB system), and let the ADB client inside the Docker container talk to it through a proxy.
While there are many ways to run the ADB server on the Mac host and connect to it from inside the container, I found this existing Java utility does it in a simple way: https://bitbucket.org/chabernac/adbportforward
There are no downsides to this approach, since Android developers will have ADB installed on their Macs already.
In Calabash-Android, Ruby code calls a tiny http server running inside the device to drive the app. To call an http server running inside the device, Calabash uses ADB port forwarding: ADB forward tcp:xxxx tcp:yyyy
This routes all calls made at http://localhost:xxxx of the Mac to the http server running on port ‘yyyy’ inside the Android device.
The problem is, calls to http://localhost:xxxx will not work from inside the container because the localhost of the container is not the localhost of the Mac. Therefore, we would need to make calls to http://osx_host_ip:xxxx/ from inside the container.
But this does not work for two reasons:
- Limitation of ADB: when port forwarding, ADB only binds to the localhost interface (127.0.0.1) and not all interfaces. This means http://osx_host_ip:xxxx/ will not work.
- Networking limitations of Docker for Mac. This means there is no easy way to access the localhost of the Mac host from the container.
We can forward any traffic for a network interface to the localhost interface. This means any calls to http://osx_host_ip:xxxx/ will be redirected to http://localhost:xxxx/
We use this script snippet:
- Create a shell script called ‘started.sh’::
2) This is how entrypoint.sh looks:
3) This is how a test runs:
While the exercise was to deliver the automated tests as a fully self-contained solution I compromised with a small dependency of having ‘ADB’ installed locally, but as mentioned, all Android developers have ADB locally. In the end, the results were great and our developers started using tests to reproduce bugs and to create complex test data. This certainly enhanced the importance of automation at Badoo.
That’s pretty much it! If you have any questions or suggestions, feel free to drop them below.
Rajdeep Varma - Automation QA Engineer