The Uber Octopusby Taylor Stapleton

I had the opportunity this week to learn first hand about some of the technology Uber uses behind the scenes in testing. While at GTAC I got to meet and hear from Apple Chow (Engineering Manager) and Bian Jiang (Senior Software Engineer) of the Mobile Infra Team at Uber. Before I move on, I would like to acknowledge that yes, you read that correctly. There is a human female named Apple. Well, ol' Apple and the gang claim to have a unique testing problem to solve in the way that Uber really has two apps instead of one. Uber has the driver application and the rider application and in some cases, there will be a combination of many rider applications interacting with one driver application (think Uber Pool). To solve their "unique" problem they developed a tool called Octopus. One could imagine an octopus with its many legs controlling many phones concurrently.

So the point of Octopus is that it can help handle complex end to end test scenarios where they want to test the interaction between multiple applications. The kind of test this is meant for would be something along the lines of something that would be well suited for a manual test where two QA people interacted with each other on the device or something. The main feature of Octopus is that it has a way for applications running on devices or in emulators to be able to talk to one another. Specifically, test runners running on each instance can talk to each other to have one big collaborative test scenario per se. The communication they have developed is branded in the Octopus tools as "signals" and the writer of the test scenarios is provided with two main API's. readSignal and writeSignal. Reading a signal naturally is blocking, and so that helps to control the flow of the tests. In case its a little hard to picture, depicted below would be an example test scenario.

I didn't get the full story of how it's implemented on the back end, but here are a few details I was able to gather from the Uber engineers:

• It works for both Android and IOS applications.
• When running on physical devices, it is necessary for the physical devices to be connected to a special Octopus hardware hub.
• When running in an emulator it is necessary for the hardware hub to also be emulated through use of writing to various files.

So let's talk about this solution. My first thought is that it seems like a pretty expensive solution to being able to run two applications in parallel for a test. There is a lot of software going into this and on top of that, there is a dedicated piece of hardware that sits in the middle of devices that must have required significant development as well. I get the feeling that there must be some easier ways to implement a test runner that can run scenarios between multiple applications. Even just writing out simple key/value pairs via http to a very simple server somewhere seems preferable. Maybe I don't know enough about the value proposition of the tool. :-p

Despite my skepticism though, there are some pretty cool perks to having the integrated test scenarios running, however the tool is implemented. When you actually see the demo they give of the test runner booting up 5 emulators and then performing UI actions on all the different applications, its pretty cool. In case it isn't immediately clear what this inter-test interaction is good for, allow me to explain. One blatant example I can think of: as an Uber rider, you would know when your car has arrived because a physical car would pull up at your pickup location. In an automated test scenario however, this isn't quite possible. How does the rider test application know when to continue the test scenario and acknowledge that the driver has arrived? One option would be to rely on certain UI elements but there are just so many hard problems to solve when doing any kind of element testing or screen diff-ing.

Having some backend way for tests to send signals to each other is a pretty good idea. Though I'm not so sure about the implementation (seems complicated), the overall effect of the signals is pretty cool. Hats off to Apple, Bian, and the other Uber engineers that built Octopus. And if any of you someday discover this post and want to leave a comment on why you did things the way you did, I would be thrilled to know.

Why is compiling still a valid excuse for messing around?by Taylor Stapleton

Everyone knows it's OK to have a YouTube video up and playing on one monitor as long as you can visibly see something, anything, compiling on the other monitor right? Because it seems to be a widely accepted notion that you are going to spend a certain percentage of your day just compiling your code waiting to get all the juicy details on where you accidentally passed objects instead of pointers so you can fix them and compile again. It seems only appropriate that I kick this blog off in its early days talking about something that sincerely boggles my brain. Would someone like to explain to me why it's 2015 and there are still large companies and millions of developers who are waiting ages for code to compile to get compiler-style feedback about their code? 

Picture the scenario where I develop a piece of code. I'm not entirely sure if what I did is going to work correctly or not so I have to change context and hop over to my terminal, figure out whatever build command is going to run the compiler and linker on my code, and then wait some indeterminate amount of time for it to tell me in the most cryptic language possible what's wrong. Though it seems impossible, there are still huge companies working in this work flow (at Google there are still tens of thousands of developers writing c++ in editors that barely do syntax highlighting).  I mainly have observed this problem for languages like c, c++, and python but I'm sure there are many more scenarios where this is occurring. 

A snippet from Visual Studio 2013 giving code feedback.

In the past I have had the pleasure of working in Visual Studio or to a lesser degree, Eclipse. In VS I mainly worked in its primary language, c#, and Java for Eclipse. Both of these tools did such an amazing job at giving instant code feedback. I can't even quantify how much more productive I was when working in those environments. Not only was I saving the maybe 10% of my day that I would otherwise spend compiling, but the ability to get instant feedback about the code's compilability (I'm going to pretend I just coined that term) helped me to stay perfectly in context with what I was working on without ever going away and losing focus.

So think about this: software engineers create mind-blowingly cool things every day. Most people on this planet couldn't possibly fathom the work they do. So can we all take a moment to think about how nice it would be to stop wasting even a small portion of our time on something as silly as compilation? It could take years, but would someone please develop some more excellent tools for instant code feedback? And for all the vim and emacs users out there, take this moment to possibly consider that working in a modern IDE with code feedback tools is a very valid way of life. God, what a ranty first post.