On 6th April 2018 the first AppiumConf was held. This was the first conference specifically about Appium, the mobile testing tool based on Selenium.
Fittingly, the keynote was from two founders of the Appium project. They took us through the brief history of Appium, and then left us with challenges for where it should go next. What direction should it take for the next 5 years? They also mentioned the way that Appium had been used to create music at a previous Selenium conference, of which more later.
Appium is, in a sense, the mobile-focused child of Selenium and Webdriver, so the keynote’s historical journey started there. Webdriver was browser focused, and the browser on mobile phones was the natural first target for mobile testing. But increasingly it became obvious, and now is even more acutely an issue, that native apps on phones were just as important, and had been for some time. Meaning that as well as the IE, Mozilla and Chrome drivers that Webdriver had already spawned there was now a need for iOS and Android specific drivers too.
The Webdriver abstraction had started becoming ‘leaky‘ in the face of what we needed to do in the real world. Appium was the initial and most successful response to that need, overtaking Calabash, Robitium and other mobile testing frameworks. A later talk would review what was available as the best framework to test a React Native app, with Detox and Appium (still) as the preferred options. And Appium picked as the winner (well it is an Appium conference).
There were two challenges at the end of the keynote:
- Who will produce an Appium Killer?
- How do we get the ‘secret robot lab’ people into the room?
Both a little ‘out there’ maybe? But it’s good to make your provocations memorable. Let’s take them in turn, although one does bleed in to the other.
Firstly, why do we need an Appium killer? Because of that increasingly leaky abstraction, where iOS and Android native solutions are just the start. In the future we might need to support wearables, autonomous cars, or other robots. Anything with inputs/outputs and a job to do. If automated testing works well for browsers, mobile phone browsers, and mobile phone native apps, then the highly abstracted paradigm will be the same for wearables, robots, smart homes, and much of the IoT, as long as we can apply the right mocks, stubs and other technologies. For example, take a look at the use of an ANT+ simulator in testing this wearable: Garmin Forerunner 735XT (and page down past the first map image), and, if you look further, the review also tests the optical HRM (heart rate monitor) and GPS functionality. How useful would it be to the manufacturer to be able to have a set of automated tests that could use mocks for this kind of testing? Although running around Paris also has it’s attractions.
And that leads to the second challenge. The ‘secret robot lab’ people aren’t at the Appium conference, so the Appium contributors don’t necessarily know how high to pitch the next abstraction. At least to stop it leaking too badly for the next 5 years, and then we’ll need to think again. Will we finally have our flying cars by then?
And at the end of the conference we got some more music driven by Appium.
