Appium 2.0 and Headspin University with Jonathan Lipps

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Jonathan Lips all about Appium Training, Appium 2.0 and Headspin University. Jonathan has been making things out of code as long as he can remember, which makes sense since he is the architect and project lead for Appium. Before starting Cloud Gray, he was the Director of Open Source at Source Labs and he has worked as a programmer in tech startups for over a decade, but also has a passion about academic discussions. And also recently he announced he's joining Headspin as the Director of Learning and Education program. So, really excited to learn more about this. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey, Jonathan, welcome back to the guild.

Hey, what's going on? Joe, so happy to be back.

Great to have you. It seems like you have a lot of stuff going on. Before we get into it though, is there anything you want to add that I may have missed in your intro?

I think you covered it. Yeah, let's dive in.

All right, cool. So I thought we'd start off with maybe. I think on top of mind is Appium 2.0. What was the idea behind Appium 2.0? Why a new release?

Well, you know, I. As someone who's been in the test automation industry for a while, if you follow Selenium, you'll know that Selenium releases are often discussed, planned and promised, sometimes years before they arrive. And you know, looking at Selenium, I always thought, you know, I don't know, I don't want to do that with Appium. That's just. It makes people wait such a long time. But now I kind of understand and maybe have a little bit more empathy for the people that I didn't formally understand quite as well because we've been Talking about Appium 2 now for several years. I think the first time I gave sort of an official introduction to my vision for Appium 2 was.

Oh my goodness, I think it was probably 2015. So.

I'm the worst offender here. But the basic Idea behind Appium 2.0 is that we made some decisions when we first started creating Appium that we want to unmake for the benefit of everybody who uses Appium. And the main decision we made a long time ago was for all of the different platform support to be a part of one piece of software. So when you install Appium five years ago, or indeed today, what you get is something that has built in support for iOS and Android and Mac and Windows and.

Tizen and, you know, a handful of other things as well. And it's great that Appium has this vision of broad support for a ton of different platforms. It's great that we're fulfilling our mission of automation for apps everywhere on all platforms. But what if you just want to automate iOS or just iOS and Android, or oddly, just Tizen or something like that, or perhaps less oddly, just Windows or Mac? You're getting yourself into quite a bit more complexity than you need to when you download Appium nowadays. So one of the big ideas behind Appium 2.0 is that platform support should be encapsulated in these different drivers, which can be sort of mixed and matched and, and installed piecemeal to keep your CI builds slim and fast and light. But the other thing that this opens up, this kind of explosion of drivers into their own spaces, it opens up the possibility of you creating your own driver and putting it out there for free for the world to download, or, or you creating your own driver and selling it as an extension to Appium, or you creating your own driver and hosting it internally in a private fashion just for your own company, because you have some proprietary technology that you want to automate. And Appium gives you a lot of sort of automation frameworky stuff and automation logic stuff for free. So you, you just build your own automation on top of Appium, but you don't want to share it with the world, so you can still create your own little driver and then kind of import it. So that's one big idea behind Appium 2.0, is that drivers are now their own kind of first class citizens that can live in their own ecosystem. And the Appium sort of software will really be more about managing drivers and then launching the appropriate drivers when you want them, rather than bundling all of this automation platform support itself. So we took the first steps towards Appium 2.0 a long, long time ago, which is one reason I thought that we would have released Appium 2.0 by now. So the way that Appium drivers are currently.

Built, even in this kind of monolithic Appium is, they're completely encapsulated, code wise, so there's really nothing that prevents us from making them purely standalone pieces of software. Much along the same lines as the way that Selenium treats their drivers. So that's one big piece of Appian 2.0. Any thoughts or questions about that before I move on to another one?

Yeah. So you're a really smart guy and so I assume you had a plan when you began to bundle everything together, since Selenium has always had, I think, the drivers separated. So was there a reason why originally you thought bundling everything together would be a better idea or a good idea?

I mean, I'm sorry to burst your bubble, Joe, but I think I may just not be that smart.

I don't know. This is the way that software development goes, right? You build something that makes sense and you incrementally add to it in ways that make sense. And then once the software grows and its purpose changes and evolves, you realize that what you built or the way that you built it doesn't make sense for the future anymore. And so you gotta refactor. So, you know, we did our kind of major refactor again back I think a little bit before I was talking about Appium 2.0. Back in I think 2015, we tore down Appium and rebuilt it from scratch with a much different architecture. So I think that's just kind of how software goes. It's always easy in hindsight to say like, oh well, clearly this is the direction Appium was going. But really at the time when we started Appium, it was just, this is for iOS and Android. And you know, we didn't really have a much bigger vision at that point. The bigger vision kind of evolved as we saw the need become more and more appropriate as the world itself was changing around us with all the different things people needed to start automating.

So I, I would just think out of the box it would be easier for someone just to download something. All the drivers are there right now. When you're dealing with newbies with Selenium, it's like, did you update the Chrome driver? Do you have the latest Chrome driver? I mean, is that going to be the same issue then with Appium? Can things in sync separately?

Yep. Yes and no. I think there is conceptually the same problem, which is that doing it this way means that users have to know a little bit about drivers. They can't just, boom, install Appium and then everything's there. So it does make it more complex for the newbie conceptually, But I actually think it makes life easier, even for the newbie, for a couple reasons. One is that right now installing Appium is, you know, not the easiest thing to do in the world. And every platform that Appium supports has the potential to, you know, have its own installation and dependency headaches. So if you only care about iOS, why download and.

Get all the dependencies for all the Android stuff when that might be challenging for you? I think it does make setup easier because you only have to worry about setting up dependencies for the platforms you're actually going to use.

The other reason I think it's better is because it makes transparent the kind of complexity that you're dealing with. The current situation hides all that complexity, but in a way which can lead to unhelpful situations. So, for example, right now, our drivers, as we've been talking about, are all bundled into one Appium release. Now, imagine between one Appium release and the next, the types of changes that might happen on these different drivers. So the iOS driver, which we call the XCUI test driver, or the kind of default Android driver, which we call the Uiautomator 2 driver, they're really on completely parallel, independent lines of development. So one day, one of these drivers might decide they need to make a breaking change, and another driver on the same day might decide they're just going to release a patch update. So now both drivers have been updated and we want to bring all of the changes from all the drivers into the next Appium release. But what do we call that Appium release? Is that a major release? Is that a patch release? It means that right now, everybody has to be really careful about reading the Appium changelogs before they upgrade any Appium version. I think we see that in the community is that there's hesitation to upgrade Appium versions because so much changes in between Appium versions. But really, if you're just looking at the line of development for a single driver, not that much usually changes. But when you've got 10 drivers bundled up, chances are, in between each release, something major is going to change. So what we want to do with the kind of driver independence model of Appium 2.0 is make it easy for users to choose when they're ready to upgrade features or upgrade across a breaking change for each driver. So there'll be a set of command line tools to assist with this. So this is where it differs quite radically from Selenium, is that I still envision drivers as being managed by one overall kind of Appium system. We're not at a stage where Apple is releasing their own driver and Google's releasing their own driver and there's nothing to really tie them together. There's going to be a sort of management tool for Appium drivers that let you install and check versions and upgrade, but not upgrade past a breaking change for a particular driver that I think will end up streamlining the whole process. So you won't actually have to go to a website and click a button to download Chrome driver for Appium. It'll be a command line.

Command that you run Appium driver, install Chrome or something like that, and then it will automatically download it for you. So everything can be handled within one interface. That, you know, again, thinking towards the future, we could even build that kind of stuff into Appium Desktop so that people can manage all this with a point and click interface as well. So I think the experience is going to be a bit different from what I agree with you is a little bit of a hassle.

On the Selenium side, this makes sense. I'm thinking of a user case I encountered with Selenium where we had to use an older IE driver because a change that broke because we had to support older browsers. So it sounds something similar. So if something occurred that way, you have more choice on when to upgrade what drivers and when.

Yep, exactly. You could use an iOS driver that was a year older than the Android driver you're using for whatever reason, if that's what your requirements are.

So it sounds also like you mentioned plugins and this sounds like a neat concept. I know you've been messing around, I think with test project and they have this concept of add ins. Is this the same type of vision you see for Appium? Like people creating their own plugins for Appium with this model?

That's right, yeah. And this is the other big component of Appium 2.0 that I'm really excited about. I think it's even more exciting than the kind of driver independence or being able to create your own drivers and yeah, so basically the idea behind plugins is that we would give developers, anybody out there who wants to write some Node JS code or a little bit of node JS code and code that it interfaces with another language or whatever would give them access basically to the Appium command lifecycle so that they can hook into an incoming Appium request from an Appium user and can do anything they want with that. They could pass that request through to the Appium server and modify its response, or they could intercept that request and do something entirely different.

The reason that we came up with this model was through a plugin that I developed a while back with test AI. And now this was before Appium 2.0. But this test AI plugin is an example of the kind of thing that would be a kind of classic case of an Appium 2.0 plugin, where the way it would work is, you know, I would write a little bit of node JS code that would extend a certain library from, you know, the main Appium project. And I would say in this extension that I want to listen for all the Find element commands. I would listen to the Find element commands and I would have a conditional in there that would say, if the find element locator strategy is AI or something like that, then don't pass this on to the regular Appium driver. Instead.

Send that command onto my element classification machine learning model and based on what I get back from there, create a new set of elements to return to the client. So I kind of bypass the iOS or Android systems and instead send that find element command to something entirely different. So I could think of a lot of examples of plugins that could work like that. But really I'm just kind of excited to see what other people think of. And what's amazing about this idea is that it, it opens up the possibility of an ecosystem for Appium where people can choose their set of plugins from the community based on what's useful for them and even a lot of functionality that's currently built into Appium. I think we would kind of move to be a plugin. So, for example, some of Appium's image processing capabilities have pretty.

Complex dependencies. They require installing OpenCV on your system and all that. So we don't want to install those things by default when you install Appium, but then that means that feature isn't useful unless you follow additional instructions. Wouldn't it be great if you could just Appium plugin install image library or whatever, and that would, under the hood, install OpenCV for you and get this plugin ready that would give you access to all of Appium's image image features. So again, it kind of enables you to not install what you don't need to use in Appium and save yourself the time and disk space and download time of getting all that ready in your CI system as well.

Yeah, I love the idea of the ecosystem. It sounds like it really could explode because a lot of times you may have a little niche of people that need a certain functionality that not everyone needs and you may not even know about it. So opening it up, I could see all these different user cases that you may not even thought about come to life.

Totally. And I mean, I like thinking about things from an entrepreneurial perspective. I hope that there's an awful lot of high quality open source drivers and plugins, but I also think it'd be cool if people came up with something really valuable or maybe that was built on their company's proprietary technology and they sold it. I think it would be awesome for there to be a kind of business ecosystem around Appium functionality as well, where people could compete based on the quality of their plugins and users could pay them for their hard work.

Absolutely. That'd be very cool development if that happens for sure. So I think also with the new Appium, do you have new drivers like I thought I saw somewhere? Espresso or window driver or even a Raspberry PI driver? Can you talk a little bit about maybe some new drivers?

Yeah, sure. So, yeah, the espresso driver came out of Beta sometime 2019. I forget exactly when, but basically it lets you target Google's espresso technology, which has a couple different benefits, including the promise of less flakiness, because espresso blocks test automation commands until the UI is in what it believes to be a stable state, which can be useful. So there's the espresso driver, which takes advantage of that. We also have the Windows driver, which is developed by Microsoft and enables you to automate Windows desktop apps. If you want to look at some of those in more detail, head on over to my website, appianpro.com and there's full articles on each of those that have examples on how to get started. But one of the more interesting ones that's potentially less useful, as Joe mentioned, was the Raspberry PI driver, which I demonstrated last year at Appium conference in India. Basically the question there was, what does it look like to automate an IoT device? IoT devices don't have. They don't always have a screen with user interface with UI elements and things like that. They might just be a hardware device that sends electrical signals somewhere. So my question to myself was, can we design an Appium driver to trigger electrical impulses using a Raspberry PI? We were able to do just that, where basically we overrode the send keys function to be able to basically tell a Raspberry PI whether it should turn one of its GPIO pins on or off, which could then let you remotely control something that's hooked up to that Raspberry PI. So the demo that I built was basically I built a drum machine using a circuit Playground Express from Adafruit. And then I built this Appium Raspberry PI driver that drove a Raspberry PI to send signals to the circuit Playground Express and play some drum beats again in a purely automated fashion. So if you find yourself in a position where you're wanting to figure out how can you actually test some hardware in this way? There's an Appium driver for that.

No, it's very cool. I'll definitely have this in the show notes a little bit more for this because it was a really cool demo for sure. Is there anything anyone needs to be worried about if they're thinking about upgrading when it comes out to Appium 2.0? Anything they could do to prepare ahead of time?

Yeah, that's a good question. I mean, I really don't think there'll be that much to be worried about. It'll really be more of this kind of driver independence thing. So what they would need to look out for then is when new major versions of the drivers themselves are released, they might want to have a look at the changelog because there might be some breaking changes there. But Appium 2.0 itself isn't really about making lots of breaking changes. We might make some because there have been a number that we've held off on for years because we haven't wanted to bump the major revision.

Or bump the major version. But those will be well documented and certainly I'll work on a migration guide and publish it somewhere so folks will have some peace of mind. But really I don't think that the changes will be that drastic. It'll be more just again, getting us into this new situation where they will have more transparency into drastic changes.

Happen with.

You do have a new gig. I'm just interesting. I'm interested in learning more. I'm sure all the folks are what the new gig is about, how it's going to affect maybe your involvement in Appium or if people are worried about that. Any thoughts around that?

Yeah, that's a good question. So honestly, my new gig is a bit of a surprise to me too. It happened pretty quickly.

Quickly in one sense and slowly in another sense. Slowly in the sense that I've been working with this company, Headspin, for over two years. Before this gig, I was running my own consulting firm called Cloud Gray and Headspin was one of my clients for a long time. And we actually Had a great relationship and I was technically an advisor to the company. So I was kind of helping them think through their Appium strategy. And I was just always a fan of their approach to engagement with Appium. And they hired an Appium maintainer to make sure that there was more investment in the project. And they gave back a lot to the community and I think just really got kind of the Appium vision. So I've always been sort of a fan of them. And as a company, I'm sure a lot of folks are aware they've been growing and.

Fairly successful in their growth as a business too, which is always good to see for an Appian cloud. But really what sparked me joining up with them was seeing a real opportunity for Appium specifically and test automation more generally in the area of education. So I mean, we have been for some time in a period of time in the industry where folks are really wanting to increase their skills, especially around automation. And you know, your events have been helping people with that for years. So this isn't a new thing. But I think we're coming up against sort of a tsunami of this, of people who are really kind of wanting to be a part of the last major wave of transitioning from manual QA to automation and things like that. And.

On top of that, of course, we've got the current health crisis around the world with the coronavirus and people being stuck at home and kind of in need of online only forms of instruction. So all of this kind of combined together in a way that made me think there's a real opportunity for training for Appium and for other things. And I've been running Appium training as a core part of my consulting business and always loved it and always got really great feedback on it and even recently started running Appian Pro branded workshops publicly and selling tickets. And so had great, great turnout and great feedback on that. So it just seemed like, you know, there's, there's something here. What would it look like to like take this online and really try and bring not just tidbits of training, not just an hour here, an hour there, but an entire like semester course, you know, 20 plus hours of really high quality video and audio and slides. And you know, what if we could, what if we could really like evaluate people based on their code samples that they're writing and what if we could actually certify them because we have a high degree of confidence in how they've learned the material? It just seemed like there would be a huge amount of value there. And I was thinking about doing that on my own. And as I kind of counted the cost of that endeavor, I realized that to successfully tackle this business problem, I would need a team. It turned out Headspin was thinking along some similar lines and we already had a great relationship, so just made a lot of sense to throw in together and to.

Leverage all the resources of a company like Headspin and the design and the marketing and the engineering and all that together with what I've already been building out in terms of pedagogy and my experience with Appium. So it happened really quickly at the end of the day, but I'm super excited about the potential. You know, we were planning on kind of working slowly on a very high quality course, like I just mentioned, this really long 20 plus hour course and releasing at some time later this year. But when I joined, we just got really excited and we were like, we just got to get something out there now. So we built up a quick platform we're calling Headspin University. Put out some video content that I'd already created and then this week I'm actually in the middle of recording a portion of a kind of live workshop. So that's what I was doing right before I got on this interview with you. And it'll be released really soon. And the idea is it'll be basically a free couple hour version of the beginning part of one of the Appian workshops that I've been running around the world. So there seems like there's a ton of energy around.

Training and education in this space and I'm just excited to be part of part of it. And that's more or less why I joined up with Headspin.

Very cool. So you did mention you always wondered why people announced versions ahead of time and they waited years before it was actually released. Sounds like this time you actually announced it and you put something into place. So it looks like you learned from that lesson for sure.

Yeah, yeah, no, it's fun. It's been a whirlwind. I don't know if it's like part of why the company is named this way or if it's like a rite of passage for new employees, but my head is definitely spinning. But it's been awesome so far.

Where can folks find out or get their hands on Headspun University? Could people log in now and register and that whole thing?

Yeah, yeah, for sure. There's content that's up and then depending on when you publish this, there might already be this new workshop that I'm talking about available.

If you go to Headspin IO, I think there's a link on the front page. Otherwise I'll give you a link that you can put in the notes there as well. But yeah, people can sign up and check things out.

Okay, Jonathan, before we go, is there one piece of actual advice you can give someone to help them with their Appium testing efforts? And what's the best way to find or contact you?

Oh man, so many pieces of actionable testing advice. How to pick just one well, one thing that I discovered recently with Appium's Touch Action support is that there's a slight difference between the Android and iOS versions of the API, where if you want to perform a swipe that takes say 500 milliseconds, on Android you encode that as the duration of your second touch move, whereas on iOS you encode it as the duration of a pause event that comes right before your move. So that was something that I learned about, or learned again about I should say, recently and implemented into a helper function. So I feel like a lot of people may not know that. So.

Dig a little more into that if you're interested. I think I have a recent Appian Pro article where I discuss how to build up some Touch Action helpers in your own framework where I also share that information. So yeah, best way to get in touch with me subscribe to my newsletter comes out more or less every week@appiumpro.com or you can find me at jlips on Twitter. Also recommend following Appium devs on Twitter. That's where we announce versions of Appium, things like that. And then of course check out the new Headspin University.

Thank you Jonathan for your Appium awesomeness. For links to everything of value we covered in this episode, head on over to test guild.com a300 and while you're there, make sure to click on the Try it for free Today link under the exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. It's been 300 episodes since I started, so thank you for listening. Really, it's been awesome and hopefully we have at least 300 or more to go. So if you have any ideas for any topics or speakers that I haven't covered yet, and the 300 episodes I've had, make sure to send me an email@joetestguild.com so that's it for this episode of the Test Guild Automation Podcast. I'm Joe and my mission is to help you succeed with creating end to end full Stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.