So in the previous chapter, I did touch on the native frameworks such as Espresso and XCUI test.
So within this chapter, I'll actually take a moment to review.
There are a couple of different ways you can run your native framework scripts on Kobiton's real devices. So I can show you just that, as well as introducing one of Kobiton's features called a virtualUSB. So to start, I'm actually to navigate back to the portal and show you all one way you can run your native script on a Kobiton real device.
In this way, I kind of like to put it as you're using an additional script to kind of handoff your native script onto the real device. That makes sense. So with that, we can actually click the three dots here on any device we want to make use of.
So let's say I have an Espresso script, with the native frameworks whenever you complete a script and you like to run it on a real device, you actually have to. If you're not within Android studio code or Xcode, you have to essentially build and package that test runner along with the application under test. And so with this additional script, what it will do is will essentially take just that take your test runner, an application under test and essentially pass it off and place it on a real device so that it can unpackaged itself and run on that real device.
So let's say have an espresso script or a test runner that I want to run on this Galaxy S20. What I can do is with that second script in mind, go to the three dots here and go to automation settings. And we'll select the framework we want to work with that we're wanting to run.
So now navigate to espresso and further you can actually select the language that you're working in. So this is not going to be the language that you are Espresso script or XCUI test script is created in. Reminder for Espresso it can only be Java and then XCUI test is that Swift or Objective-C languages.
This is actually going to be the language that you're using that second script on, which is not which does not have the limitation of either being Java or Swift or Objective-C. You can actually make use of any of the languages that you're familiar with, such as Java or Python, or C#. As I make changes here to the left, the automation settings do are dynamic and they will actually kind of update depending on the changes that I make on the left. It will update on the right here.
So we've selected Espresso. We're working in the Java language here. You can do a couple of additional settings you can make use of. So changing the session name, giving it a description, you can always change the session time out or test time out. Let's say I want to use a specific device. I can see that I will change the UD ID of that device within my settings. And then maybe I want to use a native application.
I can select that from the app repo. And this will be your application under test. And then here you can actually upload your test run and you can upload your Espresso scripts that have been kind of built and compiled within a test runner. So with that, I would simply just copy these automation settings, paste it into the script I want to make use of to kind of hand off the test runner on a real device and be able to execute that script and be able to run in your native framework on a Kobiton real device. The same can be done for iOS devices.
So if I want to run my XCUI test scripts, we can use kind of that additional script handoff. I can do the same essentially within navigating to automation settings, selecting XCUI test. Maybe I'm in Python this time and also once again select the application under test as well as upload the XCUI test script runner or test runner. Excuse me. So once again, this route is making use of kind of handing off a test runner that has already been packaged, essentially.
Already built in packaged to place it on the device. And then I'll go ahead and run your native framework on that device. This is a faster route only because your scripts have already been kind of packaged and there's no additional length of time to say compile them or what have you. They are already packaged and ready to run on a real device.
But as you might, you can kind of see that making use of kind of this additional script handoff might not be ideal. Maybe your Android studio code or Xcode and you want to be able to just run your script on a real device from there. Android's really great of using offering emulators and Xcode is really great in offering simulators, but at the same time, nothing beats real deal that is real devices. Especially maybe you're building out your script.
You want to kind of have your iterations of running and debugging on a real device within your IDE of choice and not having to continuously kind of package that test runner. You make use of that second script and then kind of run it that way.
That might be a little bit I know I say kind of productive, but maybe not as viable as, again, just running straight from your IDE. So with that I'd actually like to introduce Kobiton's feature Virtual USB. So how virtual USB works is that it acts as if you have a real device locally plugged into your USB port right within your machine itself.
So when an Android Studio Code and Xcode, you can actually connect to that device and be able to run your scripts from right within your IDE. So virtual USB has the ability to kind of make use of remote devices that you can still connect to your IDE. So let's say I had my Espresso script and I actually want to make use of that Android studio code. I can kind of connect to this Galaxy S10 here. And then if I navigate to Android studio code.
To start, I have my emulator that is running on previously, but now let's say I can actually connect to that real device. So here you'll notice that it went from the emulator to that Samsung, which is that Galaxy S10 that I just connected to via virtual USB. So once again, I can connect to a real device or a real remote device.
And as I'm building out my Espresso script, whereas I want to run my Espresso scripts, I can make use of a real device by connecting via a virtual USB. The same can be done for Xcode. So let's say you have an XCUI test script. I like to run on a real device, but I'd like to run it from Xcode. I can actually make use of virtual USB in the same way as Espresso, and I can go ahead and connect to an iOS device. Let's say this iPhone 11 pro here. We can connect and then I can navigate back to Xcode. And select now that device that I want to now run on.
This is great because you don't lose any functionality within your IDE. So with Expresso and Android studio code, I can still make use of the ADB shell, really rich debugging, and that Android studio code offers. In the same four Xcode. Xcode itself also has some great functionality that I can use when I'm creating my scripts.
And so by connecting to a real device via a virtual USB and running your scripts on a real device via virtual USB, you're not losing any of that functionality within your IDE. So it really helps facilitate your native frameworks scripting as well, being far easier to execute that script on a real device. And so it is a great powerful feature to make use of when you want to, when you're using the native frameworks.
And as a quick kind of overview, an introduction to virtual USB and the ability to run your native frameworks on a real device within your IDE. And of course, like I mentioned, not losing any of that functionality of your IDE. So say Android Studio code or Xcode?
Comments are closed.