Run Ios Apps On Android

hello, and welcome to the second episode of our appium tutorial series. today we will be installing and running appium on os x, as well as writing our first appium test and running it live on a real device we have connected to our machine. for the duration of this tutorial you will be able to see what is happening on the screen of the device

Run Ios Apps On Android, in the window to the right. the first thing we'll need to do is to grab appium itself. this can be done by visiting http://appium.io since we will be writing our tests in java, we'll also need an ide.

in this case i will be using intellij idea, but you can stick to your ide of choice. as dependencies for our test, we will need: the appium java client (in this case i'll be using version 3.3.0) and the selenium standalone server too, in this case we will be using version 2.48. and, last but not least, we will need xcode version 5.1 or higher. we must also not forget to enable ui automation on our device.

this is achieved by navigating to settings → developer options and ticking "enable ui automation" once that has been taken care of, we can actually install and run appium. the first time we run appium, we will be confronted with a screen that looks more or less like this. from here, we will be able to start the appium server and the appium inspector, which we will need to find ways to access the app's ui elements. before we do that though, we need to spend a minute on configuration. since we will be running our tests on ios, make sure ios is selected as the current target platform. once we open the ios settings tab, we see there is a lot to be customized here. fortunately, we won't need to fill in all the fields. one that we definitely need to provide, though, is the app path.

for the purpose of this tutorial, i will be testing the komoot app, and this means i need the komoot app .ipa, which fortunately i have right here. once that has been taken care of, we also need to activate the "force device" field. don't worry about the actual device, this is used for the device name, so you can actually input whatever you want. next up is the udid. this is the unique id of your connected device. to get to that we just open xcode... ...navigate to the devices window... ...and select the device you want to test on; here, we will find the udid under the "identifier" field.

we will also need to select the "full reset" option, so that after every test our app gets uninstalled... ...and the data from the app cleared. this ensures that every time we run a test we have a clean start. we will also need to navigate to the advanced tab, so we can make sure that the xcode path points to our actual installation. that's it, we are finally ready to launch the appium server. you will see the logs start to fill up. and, once you get the first "200" response from the server, you can actually run the inspector. what this will do is actually install the app on the phone

and open up the inspector ui, which you should see in a second. as you can see, the komoot app has been launched on our phone... ...and the inspector should follow soon. this is the appium inspector. what it allows us to do is to select elements of the ui, as these buttons, for example. what we see on the right side of the appium inspector is not another live feed from the phone. this is actually a screenshot of the ui of the application that we have just installed. by clicking on elements in this screenshot we can select ui elements from the application.

we can also explore the whole ui through the frames on the left. this allows us to select any element in the ui. once we select an element, this will be highlighted in the screenshot. once an element has been highlighted, we can see its details in the central frame. we will be using this information to select ui elements and interact with them in our appium tests. now that we have a way to reference elements in the ui and a working appium instance, we can start writing our tests, so let's open idea and create a new project. in this tutorial we will be using a basic java project, but you can grab the dependencies we have manually downloaded before through gradle, maven, or however you prefer.

now that idea has created a project for us, we can create our test class. since we will be using junit to run our appium tests, the first thing we need to do is think about our setup method. what we will be doing in here is, first of all, setting up a connection to the appium server. before we can do that though, we need to navigate to "project structure" and import the dependencies that we need. the first thing we need to do here is instantiate an iosdriver. to instantiate the driver we need to pass over two things: first, we need to provide an endpoint. in this case, we will be providing "http://127.0.0.1:4723/wd/hub", with 4723 being the default appium port.

in this way we will be communicating with our local appium server. that's not enough, though: we need to provide some capabilities as well, so we first create a desiredcapabilities object. the only capability we need to set for now is "devicename". again, the device name can be whatever you want. this is kind of weird, but bear with me. of course we have to take care of an exception here. in this case, we will just throw it, since we don't need to handle it. so, with the code we have written until now,

what will happen is: every time we launch a new test... ...we will be establishing a new connection to the appium server. this is fine, but we also need to end a session after a single test run has ended, otherwise we would be keeping the appium server busy with a previous stale session. this is easily achieved with a simple teardown method that will run after every test. for this purpose, we will take advantage of the "@after" annotation. here, the only instruction we need to call is "driver.quit()". for that to make any sense, we need to have a global driver. at this point we can start writing our test.

we will need to use the "@test" annotation for every test method that we write. something that is very important is to actually give meaningful names to your test methods. this means we need to be sure about what we are going to do in this method, so let's take a step back and check the appium inspector again. since we still need to make sure that our current setup is working, we will just perform a very simple action at the beginning: we will be tapping on the "log in with email" button. our method will be called "selectloginwithemail". the first thing we will need to do will be to find an element, so we will use "driver.findelement".

and we will need to provide a strategy through which we are going to look for this element. in this case, we will look for the element by name. basically, we will provide the text value... ...of the "log in with email" button, which you can see up here. we will just copy it and paste it in our code. once this has been done, we can just go on and click on the element. we could now try and run our test immediately, but if we did that, our test would fail. that's because we still have the appium inspector running. this means the server has an open session that's already busy. we need to get rid of that before we can run our test. to solve this problem, navigate back to appium inspector, close it and restart the server...

...then wait for the logs to fill up again... ...and then you know you are good to go with your tests. so let's run our first test. we check what the appium log is saying... ...we've seen that a new session has been started. the app is getting installed on our device right now, so we should see it pop up at any moment. there it is. now we should see the screen change, because we will be performing a click on "log in with email".

our test has succeeded. but did we really just write and run our first appium test? sort of, but not really. we have just remote controlled our phone and performed an action on it. we can see that the button was found and clicked correctly because the test succeeded, but we were not checking anything more than that. what we want to do now is to write a real test. something that reproduces a possible use case and checks against an expected outcome. to do so, let's restart the appium inspector and navigate through the application until we have found a possible use case that we can automate. let's focus on what happens after we click on the "log in with email" button.

as you can see, we are taken to a different screen in which we can input email and password, just as you woud expect. what we will be doing here is actually type some invalid email address. and a valid password. then we will be clicking the "log in" button. at this point, we will get this error message, so we know what we want to check against if a user is entering an invalid email. let's now switch back to idea once more and let's immediately change the name of our test method, before we forget. our new name will be "loginwithinvalidemail" what we need to do now is think about the interactions that we will have to automate. immediately after clicking this first "log in with email" button,

we will be presented with a new screen containing two text views (or text fields)... ...and a further button to confirm that we want to log in with the details we have just provided. let's say we need to insert our email credentials, which will be the first thing we need to do after clicking the "log in with email" button, then we will also need to insert password credentials. after that is done, we will need to click the login button. we don't just want to perform these actions and then stop, though: we also want to check against a particular error message (the one we just saw). so here we will have some kind of assertion which asserts that the error message is correct. now we need to navigate back to the inspector, select the elements we need to interact with,

grab them here in the code and then interact with them accordingly. let's now switch back to our inspector... ...access the second screen by clicking on "log in with email" on our phone... ...and then by hitting "refresh". again, this is not a live feed from the phone, so every time you change screen or something changes on your screen you will need to manually refresh it. and now, as you can see, we can select the email field, password field and login button which we will need. first of all, we will be referencing the email field. there is a variety of ways to do this. right now i am going to show you how to do this through xpath.

we won't be using this xpath query that you see here in the central frame for a simple reason: this query is automatically generated by appium, and what it is doing is basically starting from the very root of the ui hierarchy... ...and going down through each element until it gets to the one we have highlighted... ...using indexes on every single element of the chain. what this means is that this query will be extremely brittle, meaning that if anything changes at any point of the chain if any new element is introduced, for example... ...the query will break. and that's in the best scenario, actually...

...because of just random chance, you will find yourself with a query that is now selecting another element... ...because it might also be that, due to random chance, you will find yourself with a query that is now selecting another element... ...and this might even cause you to waste some time trying to understand why, all of a sudden, your test is doing something it was not supposed to do at all. what i suggest you do instead is: click on the "copy xml" button. this will copy an xml representation of the ui hierarchy straight to your clipboard. then, open your browser and navigate to any website that offers you the possibility to test an xpath query against an xml, paste your xml there, and then build your own query. in this case, we will try to grab this uiatextfield element... ...which is inside a uiatablecell, which itself is inside a uiatableview.

if i am lucky enough, there are probably only two uiatablecells on the screen, so basically this one and the one below, containing the password label and the password field. so i can do something like this: i will select all the uiatablecells... ...or, actually, just the first one... ...and, inside there, i will select the only uiatextfield. as we can see, this query returns one element, which is what we are looking for. and that element's value is "email", so if we go back to the inspector we can see we are probably selecting the right element. now we just copy our query...

...go back to our code... ...type "driver.findelement(by.xpath(..." and paste the xpath query we have just built. in this case we are not just performing a click on the email field, we want to send an actual string, so we will use the "sendkeys" method. in this case, we will send in "invalid@gmail", a clearly invalid email address. of course we can do the same for the rest of the elements that we need to select. so now we can also select our login button... ...and click it as well. the last thing we need is the error message, so we will go back to our phone...

...simulate the interaction that we are automating.... ...and we will go back to the inspector, refresh... and now we can get the error message. after testing our new xpath query, we can proceed to find our last element... ...which, in this case, is the alert itself. once we have the element, we want to grab its text and wrap it into an assertion... ...stating that the content of this element must be equal to... ...(and here we just paste the expected error message, which is "invalid email")... now we should be ready to run our test. what i can tell you though, is that, unfortunately, this will not work.

if you go back to our application and you try to log in again... ...you can see that it takes a split second for our message to show up. the problem is that here, appium will try to get the element immediately after we have clicked "log in". appium might be too fast in doing this. what we should do instead, is actually wait for this element to appear... ...and set a timeout, so we'll wait for this element for 15 seconds.. if it appears within 15 seconds, we will then get its text and... ...do this assertion to find out if we are correct about the content of the error message. we create a new "webdriverwait" element...

...to which we have to pass the driver and a timeout (we said 15 seconds)... ...and we can wait until an expected condition is met... ...in this case, the presence of the element located by our xpath query. so what we get from this is a mobileelement... ...that we can call "errordialog"... ...for which we have waited up to 15 seconds. we can write "errordialog.gettext()" and see if it equals "invalid email address". so now we finally run our first appium test and see how it goes. we can see our app has been launched. now we click on the "log in with email" button...

...we fill in the first field with our invalid email... ...we switch to the second field, send in our password... ...then click on the "log in" button... ...and we get our error message, which we check against... and our test succeeds. congratulations on running your first appium test on ios! we hope this video has been useful. if you are interested in running appium tests in the cloud on multiple devices, please visit us at https://testobject.com

Tweet

Subscribe to receive free email updates: