 So, welcome everyone to the Hello APM setting up your first APM test efficiently by Boro Singh. We are glad that they can join us today. Just a small reminder that below you will be seeing the chat I can please type in your comments over there. And if you have any questions then there is a Q&A section just besides that I would request everyone to type your questions over there and not on the chat window. And yes, without any further delay I would ask Boro to take it over. Thank you so much. Sure. Thanks a lot Nitesh for that wonderful intro. And good morning, afternoon, evening or night wherever you're joining from whichever part of the world. I'm really excited to bring this talk to you. And the title is very, I think, self-explanatory. This is like your Hello World introduction to APM, the first thing that any programmer will do. So we are going to basically walk over what APM is about, what are the concepts and how do you set up an emulator and potentially end by running an Android or an iOS test. So it's sort of like an end to end thing, lots of things for me to cover so I'll probably jump to it. But maybe like why this talk, what was the motivation for this. So a small backstory like I started learning APM in 2018 when I joined Gojek. And I clearly remember I took three days just to get APM set up with Android, emulator and everything. It was a pain and my whole intent with this talk is to save you that pain. So let's make sure that we can make getting started with APM a little bit easier for you. Yeah, so a bit about me. My name is Gaurav Singh. I'm an experienced software engineer in test, primarily in Bangalore currently. I'm currently an engineering manager at Gojek. It is one of the Southeast Asia's biggest ecosystem for on-demand services like ride hailing, logistics, payments, so on. And by the way, we are hiding. So if you are interested in a career change, feel free to check out Gojek careers. Apart from this, you know, I'm very passionate about quality engineering and test automation. I love building scalable automation frameworks for the entire stack and high performing teams. I pride myself as a polyglot programmer having experience in JVM languages, Python and JavaScript, and I'm a proud tester. I really like exploratory testing. I find that it's one of the best ways to catch bugs. I have some courses on test automation university and I have previously spoken at PMN City GameCon. A bit of housekeeping around this. You'll find all of these slides and code already there. So if you can just go to my blog, automationhacks.io slides, you know, you can just arrive at this live page and you can actually read through the entire thing. I also have a GitHub project where I'm showcasing the code that we use. So you can just go to my GitHub account and you'll see Appium fast boilerplate. This has the Java project with all the example code and you know, instructions on how you can run the test and everything. I'll update the talk video once it's out and you know, usually you can connect with me over the blog, Twitter, GitHub or, you know, all of that. So let's get started. You know, can we have, you know, a quick start, maybe like raise a hand if you're very new to Appium or maybe like one to two months into your Appium journey. So how many people here have are in that bracket. Okay, I see quite a lot of hands raised. Okay, wonderful, wonderful. So I guess you are going to get a lot of value out of this session. And even if you are moderately experienced, a refresher never hurts, right? So let's start with what is Appium. So if you are coming from a Serenium background or web automation background, you'll feel right at home because it's an open source library to drive mobile automation. And when I say mobile apps, it can drive native apps, hybrid apps having web views inside or mobile web, and it pretty much supports the most common platforms like Android, iOS, desktop and much more. If you're part of, you know, the state of the union meeting that we had, you already know that Appium is much more than just Android and iOS. There are multiple platforms to support. One of the core features with Appium is its language agnostic. So you can choose the language of your choice, such as Java, Python, JavaScript, Ruby and many more. And you know, you can write your tests with ease. Appium does not reinvent the wheel. It wraps automation libraries provided by Google and Apple such as UI Automator to an Espresso and for Apple X UI Test and UI Automation for Windows, it's a VINAP driver. So essentially, we are not, you know, creating something new. We are integrating with existing technologies and that is great because the vendors actually have a lot of knowledge about the platform. But we give a very convenient way for people or, you know, automation engineers to make use of it. Another core philosophy with Appium is it does not believe in recompiling the app or making use of any SDK. So it drives your apps as a black box and you'll see when we talk more about some of the concepts, right? Appium is compatible with WebDriver protocol. So if you are familiar with the WebDriver API, then you will find that Appium is a pretty much straight one-on-one port with some additional features, obviously. And it's cross-platform so you can run and write your tests in Windows, Mac and Linux. So before we move forward, let's understand some of the core concepts around Appium. These are terms that you will hear quite frequently and I have a sort of, you know, diagram to make it a little bit more easy. So there are four main actors when you talk about Appium. There is the client, there is server, there are drivers and then there is the target, right? So when I talk about client, what I mean is actually the library that you will use. So for instance, all the popular languages like Java, Python, Ruby, etc. will have a client available to them, right? And what the client actually does is it wraps the API that is provided by the Appium server. So Appium server, you can think of it as any normal backend server that you might have encountered. It exposes a REST API and the client basically provides certain methods with which you can hit this API. The protocol that primarily is used is called as JSON wire protocol. And internally what Appium server does is it interfaces with all the different drivers that are provided that we already mentioned. So if you have to run an Android test, Appium server will talk to a UI automator to driver or an espresso driver, which will act as a bridge and will convert your Appium command into native commands that these frameworks understand. Eventually leading to your apps being driven on the desired platform. And if you see like the same horizontal cut can be applied to all the different platforms that Appium supports. So I mean now it's not just desktop, it's also TV apps, right, as we saw. So these are like the common terminology, right? So whenever you think of Appium, just think of it as a server. You can expect a similar client-server interaction, make a request, get a response. Everything within Appium happens within a session context. So essentially when you start, let's say a run, it creates a session. And while creating the session, we actually provide some data, right? We tell how you want the session to be tweaked. And that is called as desired capabilities. So when you see desired capabilities, just think of it as a simple hash map or a dictionary in any language. It's a key value set of pairs where you say, hey, I want the timeout to be something. I want the app to be reset after the run is done. And there is like a long list of desired capabilities that you can go through. Understanding how these works would be very vital to your Appium journey. So probably you can find that in the Appium docs. As I mentioned, Appium server is just a Node.js server that bridges commands from your client to the native frameworks, right? And when I talk about Appium clients, it's again certain libraries that you will make use of. We'll see an example of this within Java context. Lastly, there is Appium desktop, which is a sort of server as well as an inspector built into one app. And this helps you to basically investigate the app, right? And be able to understand like different components of it. And we'll see an example to this. So I think enough about theory, I think we can get started. So like what is the basic things you will need when you are working with Appium, right? You obviously want to choose a language and ID and a build tool. So we are going to use Java, IntelliJ and Gradle. You can feel free to choose any other tool or language of your choice as well. But the basic concepts will remain the same. For iOS tests, we'll need Xcode with command line tools installed. For Android, we'll need Android SDK greater than 16 and Android Studio, right? And finally, you have Homebrew, which is a general package manager, right? And you have essentially the Node server, which is your JavaScript runtime based on Chrome V8. NPM is the package manager. So all the tooling that you need to install will get installed via NPM. We have the Appium server and Appium desktop. So I guess let's start with seeing some of these in action. So like before you start, you know, some common libraries and setup that you should install. So primarily if you're on Mac, we will mostly be using Homebrew. So we'll use it to install NPM Node and then all the subsequent packages. So you can primarily just copy, you know, this command and run it in case you have not done it so far. Or if you're on Linux or Windows subsystem for Linux, then you can use Linux. If you're on a Windows platform, then there are tools like Chocolatey that also allow you to install Node and such type of tools. If not, you can always go to their site and just download it. So for my machine, I already have a brew installed. So I can just, you know, run this and you can see that brew is already set up on my machine. The next step is to install Node, which is the actual server for Appium and NPM as the package manager. So again, you can install using the Homebrew command. One other alternative could be you can go to the Node.js site and then, you know, download the LTS version for whatever platform you are on. And this could also be another way of setting Node on your machine. Mostly Homebrew is going to be very convenient. So after you're done, you just need to check the version. So you check Node's version and NPM version, right? So as you can see, I have version 14 and NPM version of six. Then the next step is actually to install Appium server. And if you want to install Appium server version less than two, which is the current stable version, then you can install NPM install hyphen G. And what this will do is, you know, it will install Appium globally. The hyphen G will install this package so that it's available everywhere. Make sure that you don't use Sudo because that causes a lot of problems. And this is how, you know, the Appium server looks like once it is installed successfully. So if I run this, you can see all the logs, but just for this talk, I am actually making use of Appium too. So how do you install that, right? So you just have the same command. You append at the rate next to it. And once it is done, you'll see an output like this. One key thing to note is like it says there is no driver or plugin installed, right? This is one big change that has come in with Appium 2.0. Essentially, you have to choose what drivers you want to install, right? And that is great because if you are not on, let's say, a WinApp platform, then why do you need to install a driver for it? So install the driver that we choose. Like we can actually, you know, install the XUI test driver and UI Automator 2. This one is for Android and this is for iOS. So I have already installed these ahead of time just to save a bit of time. But then there are a few things that we can check that. So you have now this sub command available with Appium driver list installed and it tells you what are the drivers you have currently installed. If you want to see what all drivers are available, you can just run it without this and then you can see great. So you have Mac, Mac 2, Espresso, so many different choices for drivers to use. Okay, so once you have installed Appium, the next step is actually to, you know, go ahead and start the server. So I'll just run Appium. And as you can see, we are running an Appium 2.0 server beta 16 version with two drivers already registered. I'm not have not installed any plugins, but I think that's a great new addition to the tool and you know you can subsequently install any new plugins that might you might care about. So we are using Java. We need to install Java from either the Oracle site or the OpenJDK site and set Java home. So you can either go here and download, you know, the versions, if you go for OpenJDK, you can download whatever version of Java you care about and then this will take care of installing it for you. Or you can alternatively just use Homebrew, copy this command and just run this. So you can find for Appium or you know the client to know where Java is actually hosted. So this is one common variable called as Java home that we need to set. So you can set it in your Z shell or a bash profile and then source it afterwards. This is very important step to do. If you're on Windows, you can still set it in your environment variables, the system environments that are there. You know, by this time, like if I just said I already have Java installed so I can just quickly do a check. And as I, as you can see I'm on Java 8 at this point of time. So the next thing to check is a very neat utility from Appium, which is called as Appium Doctor. And this is great for a couple of different reasons, it will tell you what are the dependencies you don't have installed. When you install NPM Appium Doctor and let's say I want to run run that currently. So I'll just say, okay, hey Appium Doctor what are the dependencies I don't have installed right so this is going to do a diagnostic check, and we'll check like okay all your dependencies are set up or not. So as you can say my machine is pretty much well set up and I hope by the end of this tutorial yours would as well be. You can see like there are some optional dependencies that I have not installed right so it tells what is not installed and then it also goes one step further and tells you. Hey, what is the use for this right so I mean this is great because you can just use it and then make sure that you install the optional dependency that you care about. Yeah, I think this slide is mostly about this there are a couple of more blogs around Appium 2.0 from Appium Pro that you can go through and aptly tools I've added the link here. So we are we are very close to you know set up for Android so like it's a couple of more things to maybe talk about. So like when you talk about Android, you know, we need the Android SDK. We need ADB which is the Android debug bridge. This is basically you know allowing you to do a lot of good things with Android. You need obviously somewhere to run the test so you either choose to run it on an emulator or on a real device and then like I'll show you how to set up an emulator very quickly. The best way to you know get all this setup is to just download Android Studio. So once you download it, it is pretty much similar to your IntelliJ sort of platform so if I just open that quickly. You'll you'll get a screen like this and essentially what we want to make sure is we go to SDK manager and make sure we download the Android versions that we care about. So as you can see, I've also installed Android emulator SDK platform tools and stuff like that. Also, it manages updates to this right so whenever you open a project it will say do you want updates to these or not so it will take care of that automatically, which is great. The other thing is you have this thing called as AVD manager. So if when once you open AVD manager, it gives you the ability to create an Android emulator. See, I already have an emulator created but then if you want to create one for yourself, you just need to come here, choose a mobile model. It's a good idea to choose maybe you know Play Store services because this will make sure that Play Store is available certain apps require Play Store services. So choosing a model like this is good, but you can also go for any other model. So this is the Android API level and also which image you want right so there are like multiple options available for the images. So let's say I just go with Android 10 for now, you can give a name and then you can also you know configure this as per your need, whether you want to configure the speed at which this emulator works or the latency and stuff like that. And once you're done just hit finish and you know it's going to create an emulator for you. So if you want to start an emulator, you just click on the play button and this is going to make sure that it launches an emulator for you, right. A couple of other things that you'll want to make sure that you do is once you have launched the emulator, go to about find the build number, right. So I guess you find the build number, you just tap on it multiple times until you get developer options enabled. And even for an emulator or a real device because it gives you the capability to go into developer options. And if I just search for developer, right, you can see developer options. The one that is most important is USB debugging needs to be enabled, right. This is similar for either your Android emulator or the real device. I'm going to just close this because I'm going to just make use of actual device to show you how to run the test, but I hope you know this gives you an idea. The one other thing that I have not yet mentioned is you know once you are done with installing Android Studio and everything, you have to make sure that your Android home is also set. So Android home is the path where your entire Android SDK will be present. So I've already given the most common path where it installs after you have done Android Studio. So you can just copy this, put it in your bash profile or Z shell RC and then source it or put it in your Windows system properties, right. So once this is done, one quick thing that you can check is whether adb is available. So I can just do adb-version and if you get a version of it installed then we are mostly good here. So I think, you know, we have hit a milestone. So we have set up everything that we need to actually run an Android test and maybe, you know, I can show you that. One other thing is all of what I've talked about is already captured in this, you know, slides. So you can after the fact as well go and just read through it in case you're interested. A little bit more thing before we, you know, actually run our first automated test. So there is this utility called as Appium desktop. Appium desktop, you can think of it is if you if you're familiar with Selenium and we had an inspector available, right. So it's pretty similar in that in that sense, you can actually open up an app and then be able to inspect the structure and then basically find locators and everything, right. So you can go to the GitHub releases path to this and download this app. If you're on Mac, you can just download the DMG and you can install it. So this is how you know it actually looks like. So I'll just show you very quickly. So when when this Mac app is installed, it gives you the ability to specify an Appium server, right. And if you can notice I have actually changed the board from 4723 to 24 because I want to run two parallel Appium servers one for my test and one for just inspecting. So if you can say here our Appium server is running right. So you can start a server this way and this will start another instance and then you can open the inspector. So what this inspector does is you know, it basically takes certain desired capabilities and then launches a session. But I will not use the Appium desktop because quite recently, we had a change within Appium community where we actually in introduce Appium inspector as a separate standalone module. And that is great for a couple of other reasons. So let me just show you that quickly and then maybe, you know, we can discuss about it. Just give me a moment. Yeah. So quite recently, I showed you Appium desktop right which has a server and the inspector bundled in one single application but then we recently got a split wherein like the server is completely bundled out this reduces the size of this install significantly and also ensures that let's say I have a server running at this point of time right which is Appium 2.0 server. I can just make use of this itself and inspect my apps. So I would recommend using Appium inspector. It's pretty good. If you want to see how to basically find that you can just search for Appium inspector right and yeah I think you can find it within the Appium GitHub project. It's again a downloadable file similar to this. So yeah I think a couple of things maybe to discuss before we you know move forward. So like basically you have so far seen I mentioned desired capabilities right. So desired capabilities as I mentioned is a key value set of pair that tells okay what are the capabilities I want on the server right. So if you see here. Let me just open the real device that I have ready at the moment. So I hope everyone can see this. Just give me a minute. Let me probably collapse this. Yeah. So this is a real device that I have you know running I'm using SCR CPY which is a utility to screen share a real Android device right. And as you can see, I have actually an app here where it's called as API demos, which gives you the ability to probably practice a lot of Appium commands. So I'm going to probably use this itself to automate and one simple flow that I will want to automate is click on text, click on lock text box, click on this add button and verify whether this text is correct. Right. That's the simple flow I want to try. Obviously when you're trying to, let's say automate this for the first time you want to figure out what the IDs of this is right. So what we'll do is we'll start an inspector session. So just to start it you don't need to do anything else. You don't need to come here to decide capabilities and then you need to paste, you know, these capabilities, I'll just give you a quick brief of what they mean. So, if this is pretty clear we are saying Android, we are choosing UI automated tool as the driver of choice. What is the Android version, the name of the Android device that that I want to use. This is important if you're using, you know, if you're given name to your devices currently, I have only one device running. So this setting will not matter much. You need to give the path to the APK. So currently, if you want to, you know, take a look at where this APK is installed. So I have a path for that already. So you can go here under sample apps in APM you'll find this APK as well as the Mac app that we are going to use. Right. So yeah, you have the fully qualified absolute path for this and you have the app package and the app activity. If you are, you know, thinking how to find the app package or the app activity. I have some instructions on that maybe I'll just yeah. So if you just if you'll go to this path you'll find I've written a blog for this and you can actually read on how to figure this out. But this is mostly a one time setup that for any new app that you're automating, you need to figure out the app package and activity and then mostly we are done. So if you come here, you set this activity, sorry, this desired capabilities and you save it with some preset name, right. So as you can see, I have this already saved. And what I'll do next is I'll just start a session. So it says, okay, automation name can't be blank, which is good. Like it's one live bug that we found. It's actually not a bug. I just need to tell the, you know, driver name. So what I'll do is I'll just go here. I'll copy this guy, you know, and I'll update it here. Okay, so I am just saying I want to choose UI automation to ask the driver and I'll start the session. And it will take some time to, you know, actually start the app. And great. So I think now what you see is it has actually booted up the app, right. And this is the app inspector in action. So this will let you know. Okay, so if I want to basically click on this text element, I can click on this and then see what are the properties for this element, right. As you can see, it intelligently also suggests certain locators that you can use. So it gives a fully flashed X path that you can use. It tells other properties about it. Also, it has actions as well. So you can just use these actions to perform, you know, actions on the app. So I just performed a tap. Let me select log text box and again tap on this. Let me click on add and then again tap. And as you can see, I can go through a flow on my app and keep on seeing what are the different screens and what are the locators I might worry about. You can also send keys or, you know, you can clear and stuff like that. So there are like a couple of other options. You have this option called as get timing, which is interesting because it will tell you out of all the available choices, which ones would be the most fastest one. So as you can see, ID is always going to be faster than any other option. So you might want to prefer that sort of strategy to actually capture that. So great. I think we have a fair bit of idea about the inspector. Now, there are a bit of other things as well. So there are like additional capabilities you can swipe by coordinates, tap it. And you know what not even refresh source and take a screenshot, start recording. So there are multiple capabilities that this tool offers, which I think you can make use of. So let me come back to this. I think with this, you know, we have set up everything we need to run our Android test. So let's see that quickly. So as I mentioned, I already have a sample project ready to go with all of this, right, but I'll just explain the test structure very quickly. So you have a test, you know, that that is basically interacting with which inherits from a base test and the base test actually reads certain values from properties, you know, and I'll explain what that means. The base test is responsible for initializing the driver connection, setting up the driver instance, and for that it is basically reading certain JSON files and taking care of that action. And also the test, you know, just interacts with a page object and the page object inherits actions from a base page. So if you're thinking like this is maybe probably a lot more detail. So I'll just show you the code. I think that will make a little bit more sense. Right. Yeah, so if you come to this apium fast boilerplate, like this is a typical Java gradle project. If you take a look at build or gradle, right, this has all the dependencies that we need. So it has the Java client, which is the client that I was talking about. It has Selenium server Selenium Java, and then it has test energy as the framework of choice. This is a run test method which basically uses test energy and then is able to run any test annotated by a group, right, so I'll probably show that in a test file and that would I think sort of make better sense. So if I go to Android test, you can see this is the simple test that I have ready, right. As a structure, it is coming under the Android group. It is extending from base test, and it basically creates an object of API demos on page, passing in the driver instance and then it just does the same action that I talked about. It opens the text taps on login text taps on add button and gets the text. Finally, it just asserts whether the text is expected or not, right. So if you go to base test, base test is like, you know, your common file that all the test file will share. And as you can see it has Appium driver, it has a properties reader, and it has two common methods around setting up your driver instance and tearing it down after the test is run, right. So if you see what we are doing basically is we are getting a target, which is basically what platform we want to run it on. And then we are passing it to a class called as new driver manager, right. So I'll just show you this class, and this will give you the actual hold on how a server instance is set up. So as you can see, I have an Appium server URL and one key thing to notice with Appium 2.0, you don't append WD slash hub. So if you're on on on a version lesser than Appium 2, you still need to append this to the server URL path. So as you can see, I have a get instance method, which basically takes a target platform, either Android or iOS. So if you go here, this is just a typical enum. And it will, you know, call methods like get Android driver or get iOS driver. What these methods in a very quick nutshell is doing is they are reading from couple of capability files. So if you see search for Android caps, you can see in resources I have this Android capabilities file. And again, I have the iOS capability file as well. So depending on what platform you want to run the test on, it's going to read that file, and it's going to basically populate, you know, our desired capabilities. So if you see here, what it does is I'll not go in the details of this method, it basically reads that Jason file and then gives a hash map, and then we just set it to get drivers method. Here you can see we create an object of desired capabilities. And this creates a new driver instance with the Appium URL and the desired capabilities map that we have just read. Right. And finally, once done, it just returns the driver instance and its job is done using an abstraction like driver manager helps you to, you know, evolve this class independently in case you want to support a cloud device lab like browser stack or whatever. And it's a very common pattern that many people with Appium automation actually use. So, enough with this I think we have taken a look at the test, the base test driver manager, and you know also the capabilities file. The one final thing is basically the page object. So if you go to page object. You can see the page object extends a base page class. So if I go here, you see, this is another framework pattern to follow with Appium or Selenium in general, wherein you wrap the third party methods into methods that you control. This is useful because if tomorrow you want to, let's say move to a different library, you don't have to change in all your page objects you can just isolate the change in this base page. So you have to not overcrowd this class. So in case you are expanding this a lot. I would suggest to you know break it out into different classes and just compose them as an object into this class. Right. So as you can see, I have very common methods for click and get text is just a plain simple wrapper over the Appium methods and I have a couple of methods around waiting for an element. It's a pretty lightweight class and in a real project, you would actually iterate on it and add much more level of capabilities for swipe tap and all sorts of other actions. Right. But the core important thing to see is in the constructor, we pass a driver instance and that is set in a protected instance so basically any child class also inherits the driver instance. In general, I have given the two sort of locators, right, if you see there is a text button and the log text button that we saw on the homepage, right. And both of them are using the expat locator. If you see there is an open text method and a wrapper to perform click and all the other sort of action. Similarly, I have another page object as well, which which is again dealing with, you know, the, the other class that we had basically the exact logging screen that I showed you just second back right. Yeah, basically this screen. So as you can see, this pretty much completes it one additional good pattern that I would like to call out is you basically return an object of either the same page object or a different page object and what that enables is you can basically chain and write your steps one after the other this is called as the fluent pattern, and this makes your code lot more concise right. So now, if I want to just run the test right so you can, I'll just run it via greater so you can actually go to this project. I have the command here, so you can just run this whole command. So as you can see, it is creating a new driver instance, right, and it just performed what what we wanted it to and it quit. So, yeah, this is probably all about running the Android test. I have added the code for all of this in this itself and you anyways will have access to the GitHub repo that you can take a look at. With with you know all the sample code so I think moving on to probably you know I was there are a bunch of additional packages that you need to install so I'll probably run run through them fairly quickly in the interest of time. So you need to make sure that export select is installed, right, Carthage is installed this basically allows the X UI test driver to build any iOS dependencies. You need to install live mobile device which is used to communicate with iOS services using native protocols, right, there is this dependency called as iOS deploy that makes it very easy to deploy apps and everything. And then there is this iOS WebKit debug proxy that that you can install so I mean, if you think about it, this will basically proxy your request over a web socket connection. It's okay if you don't know the details to be honest is just think about it as some set of dependencies that you need to set up once to enable running your iOS tests, right. So, additionally, there is this IDB as well that you know allows you it's an equivalent to your IDB bridge that that needs to be installed. So once you're done, like, I would want to also run on the iOS app right so what I'll do here is let me kill this inspector and I'll show you the app very quickly. So I'll basically run the iOS app from here. And currently, if you see capabilities are pretty much similar, right, except for the difference of X UI test as a framework choice, and we gave device name as you know one of the simulator images. I've added a command for how you can basically find the name of any simulator or whatever. It's pretty easy to do. And as you can see, this is a very simple app where it's a sort of demo app where you have, let's say two controls, and you can enter certain numbers and you can compute the sum and that is what we are going to do. The Appium inspector is pretty much same. There are no differences, apart from you know, obviously iOS comes with its own set of way of organizing elements on the UI so you have X UI element type, X field, and stuff like that. So I'm going to basically close this and I'm just going to show you the test very quickly. So if you come here, right. Yeah, so I have an iOS test, and this is pretty much for, you know, following the same pattern. So you have a homepage, right, if I just show you that very quickly. So that's the two controls that I had and a compute sum button, and I have written some methods to type in the text, right, for the two numbers compute the sum, and then finally, you know, return it. Also, one more practice that you can follow is, while you write these individual small methods, you can always write a wrapper, if it's a logical action so currently we enter two number and compute right. So I've just added a wrapper method here and you can if you go here you can see I initialize the driver instance I just call this and I use get some to get the actual value. And then I expect obviously five plus five to be 10. So to run this again, I will make use of gradle itself. Right. Let me just go here. If you can notice the only changes I'm making is the tag and the target, right. So the tag is obviously your test energy group that I have that I annotated on the test, and the target is just a property based on which I decide what driver instance to initialize. So when I run this, it will just start a simulator, and it will install something called as web driver agent. So you can think of it as a small server running within your simulators or your real devices, and that proxies any command from Appium server directly to XUITAS framework. So you can see we entered the two number and we computed the sum and this is also good. I'm so glad that there is no demo effect today. So yeah, I think you can see this very basic implementation for iOS as well. There are, you know, a couple of other things that I want to call out basically if you are running running it on a, you know, what do you say real device there are a couple of other things that that we need to take care of. So I mean, if you go very quickly, I just showed that I think I added it here. One second. Okay, yeah, so in the Appium desktop section, right. Yeah, if you're using a real device, then you need to give some additional information, which is basically what is the bundle ID of the app and the automation name, right, and the export team name and and the signing ID. So all of these details is something that you can ask your iOS developers to give and they'll be able to actually provide that to you. Finally, you know, I think they're pretty much on time, but I just want to end with couple of bonuses. So you can use a CRCP via to screen share I already talked about it. But if you don't want to use the inspector in Android you have UI Automator viewer, which is a pretty much similar utility that you can use without creating any sort of Appium session for that matter. There are like some adb commands that you know can really help you so I wrote a blog on this I've given a link here. I talk about, you know how you can install an APK via adb. How do you copy files. How do you capture a screenshot video and stuff like that so you can basically read through this just to get an idea on those commands. And I think that would help a lot. And I guess, finally, yeah, I would like to thank you for your kind attention. In case there is any questions or feedback, you can like reach out to me, you know, on Twitter GitHub wherever you feel comfortable and more than happy to answer your questions. We'll see if we have some time now. And here are some further resources that can help you to learn Appium so you can go to Appium.io to read the docs. There is this execute automation playlist that I personally started learning Appium with and I recommend, and there is another series by, you know, automation step by step by rather which is also great. So yeah, with that, you know, I am very thankful for all of you attending all the best on your Appium journey and you got this. But thanks a lot, Gaurav, for sharing your experience with us today. It was really great. I really enjoyed. It was very straightforward, etc. And, you know, no winner thingy. I think we have, you know, already some thumbs up from in the chat window. Yeah, thanks a lot, Nilesh. Let's hang out on the table.