Okay. So in this section, let's review the one route of executing your native framework script, and that is not direct connection or that second script handoff route. In setting yourself up here. What I'll do is once again, I'll be setting up a second script. But first I need to define the application under test as well as my test runner within this script. So within Kobiton, this is the Kobiton portal. These are real devices.
They are cloudified devices that they can access anywhere around the world. What I'll do is I'll navigate to this galaxy S20 here via the three dots to the right. Put to navigate to automated settings. And here, it will help lay out the script for me that I can easily copy and paste that further execute that script. So how that will look.
So we're going to make changes here on the left. As I make changes on the left, it will dynamically change here on the right. So to start, we will actually want to choose the framework we want to execute. So let's say there's an Android device. I want to run my Espresso scripts. So we're going to choose Espresso.
You can also choose which language that you want to execute a script from. So you're not at the caveat of having to be within the certain language dependent on that native framework. So again, Espresso is Java, XCUI test is Swift, and Objective-C. With this second script handoff, you can set yourself up with any language.
So maybe you're more familiar with Python or Ruby or C#, but for my example, I have my set up for Java, so I've actually able to keep it to Java language. You can give a description if you like. You can also define the timeouts and test timeouts, but I'm going to go ahead, just move on down to this section here.
So what I am going to do is I'm going to use a specific device. So upon checking this, the capabilities will be set to the UDID is specific to this device. To make use of. For the application under test, you can actually upload it from a new URL. So maybe you have a new build push to a GitHub repository.
You can link that URL to GitHub repository here and make use of that application to install the real device. Or what I'll be doing is I'm actually going to make use of an application already in Kobiton's app repo here so I can select an app for the app repo. I'm going to select this custom matcher edit text. It will select this version.
So what this does here that you can see the application that I want to test against, it does have a very unique ID with the app repo that Kobiton's server knows which one to reach and install on the device.
Here for the test runner.
So again, you can upload the test runner via URL or you can locally upload the test runner as well. Someone to do just that and select the Espresso test runner here. Okay. So once again, we have our capabilities defined.
So making use of this device, we've defined the application on our test as well as uploading our test runner. So with that, I can easily copy this script. Bring it into my IDE of choice. I can easily copy it here, but since I have a bit of a different of a syntax, I'm actually just going to manually make changes within this script.
So I do know this is the correct UDID to point to the device. For the application, I'm going to go ahead and just copy in the application. And just make some adjustments. Okay. So I have an application define. And then make some changes here. For the test runner, we'll do the same. Okay.
Within this script. What it does, making use it is making use of Appium drivers that are dependencies there that you would need to preliminary get yourself set up to run. But with that setup, I have my name and my API key to access the Kobiton server. So with that hitting the Kobiton server, I can pull the device that I'm looking to use in my testing as well as the application defined and my test runner has been updated. And this is the test framework UI automator or Espresso kind of to the same.
So with that, let's go ahead and start and run this script. Okay. For demo purposes, this is a very simple script. I believe it installs the application it makes the navigation. That's about it. I do have a session ID available for me to let me know that the session was executed and ran and now I have a session to review within the portal.
So we give this a copy here. Navigate two sessions. Here. I can see the my Espressos scripts that I ran. And here I can see my session that I just executed via that script that once again is executing my test runner of Espresso scripts and applying that or hitting that off onto the device that is then run against my application under test.
So as mentioned this nondirect connected way, the session is captured. So I have the ability to view this session. So within such an overview, like I said, there is a playback video that captures the execution of the test runner of my native framework script Espresso. Also in such an overview, we do have a recap of the application that was installed on the real device as well as your application and test runner available to you.
We do have the Espresso logs you can view and download. We also have an API endpoint. Kobiton's API endpoint you can use to pull these logs from a programmatic perspective. And Kobiton also has an API endpoint to pull the information, the metrics captured in this session for additional reporting. So that's going to be around CPU, battery, drainage, network usage, and things of that nature. But again, kind of the exhaust put off on the device during your testing is captured and available to you via API endpoint to use in further reporting.
I would like to quickly note that this was an example using Espresso, but the same route of execution, that nondirect script handoff route can also be applied to XCUI test. So if I were to navigate to one of the iOS devices that follow the same flow, click on the three dots here. Navigate to automation settings and select the XCUI test Framework. It is two of the same. So once again, as I'm making changes left here, it will directly change the right here for an easy way to copy this script.
I can choose the application I want to test under as well as upload the test runner. And for XCUI Test. If there is a test array or test plan, I can also upload the test plan locally or from a URL also. So once again, this script can make use of running your Espresso scripts as well as XCUI test scripts be a test runner and test plan.
So this is one way to execute your native frameworks scripts for Espresso and say for XCUI test for. In the next section, we'll review the direct connection route. Making Use of virtual USB.
Comments are closed.