 My name is Isaac Merchie. I'm a core developer and ecosystem and integration developer at SOS Labs, which is a company that does test infrastructure, basically, cloud-based test infrastructure for Selenium tests. And we have an open source project called Appium, which I'm going to talk about today because it kind of opens up functional testing for mobile apps. It's not necessarily Ruby motion based. It works with Ruby motion. I've been doing that for a bit. But in general, both iOS and Android apps can be automated with Appium. It's about 16 months old, a little bit older from the first original version. And in this current incarnation, it's about 16 months. It's open source. It's had about 4,200 commits to date, over 2,000 issues that have been logged and closed, and probably 100 that are still open and pending. 1,200 pull requests from various people, 1,200 stars, 900 forks, and over 100 people have worked on it. So it's an active community of developers. What I don't have here is also a rookie of the year for open source. What I don't have here is we also have about 20,000 downloads a month. So there's a lot of users in addition to developers. And most of the users are testers. So rather than developers, this is an issue that we'll go into in why you might want to use a system like this rather than Ruby motions built in stuff. Starting with Ruby motion testing, this is from the documentation that is not meant. This is the functional testing suite. So it's not meant for full application acceptance tests. Therefore, you should not let the application launch as normal. So in your test environment, you short-circuit your application and boot out, and then you kind of are testing views and controllers individually. So it's kind of functioning as unit functional tests, as it were, rather than true functional tests. So with Appium, we have a philosophy, central philosophy is that your app that you test should be the same as the app that people will see. So rather than having something which nobody will ever interact with, you have your full app and you're testing that. We wanted it to be language agnostic, so you don't have to write it in Ruby. Say you have QA people who do the QA, and they know JavaScript, or they know, lots of them know Java for unknown reasons. So they want to use JUnit. They can use JUnit and write tests against your app, which is written in Ruby. Device independent. So this morning when I wrote this slide, didn't really matter for this group, but lo and behold, you'll have to be testing Android apps too soon. So the fact that Appium can handle sending commands and automating an iOS app and an Android app becomes a boon if they're essentially the same app. You have the same accessibility labels inside them, then you can find the same elements, do the same things to them on the two. So tests don't have to be duplicated and rewritten and refigured for your different app. And then we wanted it to be based on something standard, so we're not reinventing the testing wheel. And what was chosen was Selenium. Selenium is a HTTP based set of commands to automate originally web applications. So it's for cross browser testing, basically. So you send commands to a HTTP server and it drives your browser to do something and it's built into all of the browsers that are out there today. Selenium 3, which is currently in a draft spec, has support for mobile functionality. So things that don't happen with websites but do happen with mobile devices, swipes and flicks and this and that. So Appium is essentially a Selenium server. Rather than driving the web, it drives mobile apps. So in terms of a architecture, just like the remotion functional test suite, it is a way into Apple's UI automation. So Apple has this instrumentation that it can use, that you can use to make your device or your simulator do what you want it to do and you have to write it in JavaScript. If you want to do it natively, you're writing random JavaScript crap. The RubyMotion test suite gives you Ruby commands to access it. Appium gives you Selenium commands which are backed by calls to UI automation. So you can do anything that Apple allows you to do which unfortunately is not everything that you might want to do. Apple's not really invested in testing for some odd reason. It also allows you to do certain other things to do with setting up your environment and testing things that might happen to your app. So blocking wifi, blocking any kind of cellular signal that might be simulated through the simulator or on your device, setting location. So if your app deals with locations then you can set where you want it to be and then test that it knows that that is what is happening and it gets the right data for that location. The next big part of the architecture is that it is a client server system. It's a Selenium server on the back end and a client in Ruby, in Python, in Java, in C sharp, in six or seven different languages we've written so far and mostly using the standard Selenium clients. So they're out there, they've been developed by other people. We've added some things for mobile testing to kind of extensions of the Selenium clients but generally speaking it is conforming to the standard. And then the second part is configuration which I think I have. So configuring what environment you want is a difficult thing sometimes. In Appium it's just a hash which gets turned into JSON and sent off to the server. So say you want to run against either a device, a real device or a simulator that is an iPhone retina running 7.1. So you set this, say the platform is iOS, the device is an iPhone retina, the platform version is 7.1 and whatever your app is, if it's not already on a device or on a simulator it will install it for you. But say you want to test against 6.1. All you've got to do is change one line in your test. If you want to try an iPad it will run it on the iPad simulator or on your iPad device. So this perhaps gives you some ideas about what might be possible with such a system. We have a client server architecture, we have the ability to set the parameters for what you're wanting to test against. So using something like parallel test gem which will allow you to run multiple tests at once, you can point to say three different Appium servers and run against iPhone running 6 or iPhone running 7 and an iPad all at once. Or say you only want to test against an iPhone but you want to do six different tests that are all kind of long running then you can do those in parallel. All you've got to do is have the machines that will run the Appium server of which there are services which will do that. Sauce is one but there are three or four others out there and competitors to us. Which brings us to scaling, which is something which the RooMotion test suite doesn't handle very well. And UI automation doesn't handle very well either. It's built into it. You can only run one instance of UI automation at once. Instrumentation won't handle multiple if you try and connect to a different device at the same time as when already running it will shut both down and go on its merry way. So that doesn't scale very well. You can't do much other than a single test at a time and if your tests are long running or you've got lots of tests then the machine is gonna sit there and try and do all of these tests. So as I said, Appium as a client server architecture which allows you to have your tests actually running the device or the simulator running somewhere else from where you run your tests allows you to open up a grid, open up multiple servers that are handling your tests at one time this allows you to do things like continuous integration. So rather than checking in code and crossing your fingers and hope that it works on all of the different architectures that you want to handle as you get into Android testing as well as Apple testing then this becomes even bigger where you want your code base to stay in line and through both continuous integration is useful. Check something into GitHub and automatically trigger tests to be run and they'll tell you that what they fail and having a client server architecture you can go to a cloud based solution as well so that you're running things in parallel on an even larger scale. So coming to what is possible with Appium or with UI automation in general this is a very basic test of getting to a view that has two text fields which you want to enter some stuff in and have them added together. So you want to enter them in one not be able to press the add button enter it in another then be able to press the add button and have it actually produce the sum of the two. So you'll see that you can find random elements. This one happens to have a name which is editing. The name corresponds also to the accessibility label so these are usually there anyway if you're working well and you can click on elements that are clickable. You can tap them, you can press them, you can long press them. Very any of the gestures that you might want to do in order to test that you can move around in your app in the right way. And then you can assert things. So asserting that a text field has the text that you want in it. You can send text to it. So sending keys will actually invoke the keyboard on both the device and the simulator. So it's actually going through how you would do it if you were actually interacting with your device rather than some nefarious means which doesn't test your actual system. And the rest is basically the same. Finding elements, sending keys to them and asserting that what you expect to be in them is in them. So when you send 42 to a text field you expect when you say what's the text to come back with 42. If you don't, something's wrong. So as Colin said, in the panel there's a checklist of things that he has the testers used. You can write that checklist as a series of Selenium tests and run them without having to have somebody, some fallible person with a pen, checking them off and say, oh, I didn't want to do that. Worked the last hundred times. The computer will just run them. Tell you if something's wrong. So if you've ever used RSpec before this should look exactly like RSpec, it always looks. That's all it is, it's an RSpec test. It's using a library, the Selenium library to get these extra commands, but otherwise that is it. I have a demo which we will try to work out. There's nothing really more boring than watching tests run but we'll let you run, watch one of them at least. So this is a recording I did because there's too many moving parts, I'm sure something would fail if I were to try to do it live here. But this is the test that I showed you running on. The server output is here, just getting the HTTP commands and you get the normal RSpec-ish. Sorry, it's tiny, isn't it? And I guess it recorded something. So it fills in text boxes with random numbers and sees that it added 72 to it. I put a delay at the end so you could see what was going on. So you see, it opens up a simulator, can also be a device, it works perfectly well as real devices as well and runs through a scenario, runs through opening it from the front page, going to the page it wants to get to, doing what it wants to do and coming up with the right answer. Whatever that answer is, you might have something more complex than adding. I hope you have something more complex than adding. We have, as I said, the capability to click on things, pressing, long pressing, these sorts of things, can also do more complex gestures like swiping, pinching, zooming, these sorts of things. And in the most recent incarnation that we just released a 1.0 of it, and you can do ad hoc gestures. So taking a gesture at any point and moving it to any other point through any point that you want. So we're working on a kind of library of geometric shapes that you might want to use. At the moment, you've kind of got to, if you wanted a circle, you'd have to calculate the points to make a circle, but this opens up a world of gestures that you can use. This one is a simulation of a test which uses some of those gestures to kind of build up a more complex gesture in a visual way. It's hard to assert these gestures as part of the problem, but we'll go into a visual one and start writing. So you can imagine what you might be able to do with this and how you might be able to automate functional testing finally for mobile apps and do this in a kind of scalable way. My last little bit, I kind of thought I had a 20 minute presentation so it's a bit shorter, but there are some caveats. So the world is not all rosy. This does depend upon UI automation. UI automation has its quirks, first being that you can only have it running one at a time. You can't have multiple instances. You can't have it running on anything but a Mac. So Mac, it kind of limits the possibilities of horizontal scaling because it becomes prohibitively expensive. If you could run it all on some Linux box, you could have just an array of Raspberry Pi as running your tests on it for $20 a pop. You can only do what UI automation allows you to do. So if there are things you can do on your phone that Apple hasn't seen fit to write into UI automation, then you can't do it except for a few things like setting locations and things which we've added on and kind of bypassed, but bypassing doesn't really work very well. The other major thing about UI automation is it doesn't allow you to switch apps. So if you have an app that needs to bounce out and use Safari for a moment and then come back, you can't do that. This is something that Apple has decided you don't need to do, so you can't do it. And the last one that's kind of close to my heart is multilingual support. So you can put any text you want in there, but anything other than ASCII will bypass the keyboard altogether and just get inserted directly as the value of the field that you're trying to set text to. So if you want to put in Japanese text, you can't be sure that the keyboard is handling that. It's not being put in as a user would put in Japanese text. It's being kind of shoved in the back, basically. So other than those few little things which remain to be worked out, and hopefully Apple will be amenable at some point, my supervisor is going to corner the UI automation people at WWDC next week, so we'll see if they can duke it out. Other than that, this opens up functional testing to your mobile apps in a way that has previously not been so easy. It's possible, but difficult. All right, thank you.