So we have touched quite a bit on Appium scripting and how AI can help support your Appium scripts.

But of course, I don't want to leave up the support of the native frameworks such as XCUI test for your iOS applications as well as Espresso for your android applications.

I will preface that this section or this chapter does not involve AI or the Intelligent Quality Suite.

This is primarily highlighting the additional support Kobiton has to offer for your scripts that you might come to the table with. So for Appium, we do have the intelligent quality suite support and many of ways, as I highlighted it in the previous sections and chapters.

But for this chapter specifically, we will not incorporate any sort of AI. We just want to take a moment to focus on the additional native frameworks that can be made use of when you're adopting mobile test automation.

So we can begin looking at the differences between each framework. So once again, we have Espresso for Android, XCUI test for iOS, and then also Appium, which we've touched on that actually envelops both native frameworks.

So what exactly is Espresso? So espresso is a free and fast native framework available for UI testing on Android applications. It's baked right in to your Android SDK and can be integrated into Android Studio's. Other Espresso, there are also offers of Espresso test recorder that allows you to record interactions with a device and add assertions and to verify UI elements. These Espresso tests recorder will automatically generate a corresponding UI test. So very similar as I showed you with AI combining the Appium scripts.

But here we actually have its own vendor within Google, within Expresso and Android to really say we have a recording playback feature to allow you to run one test and then be able to kind of capture that test without bringing an A.I more of its own kind of functionality with an Espresso. Some pros of Espresso, so it's very fast.

When we look at native frameworks, it's going to be far faster than Appium or other scriptless scenarios, only because it's very intuitive to that type of application. It's kind of baked right in.

You have any unique ids available to you to kind of build out your script of it's deeply integrated with Android studio code and a source code that offers very clear failure reporting and provides rich debugging information, as well as has a very seamless UI synchronization that makes your test less flaky and more intuitive with assertions and easily to integrate with your CI/CD pipeline.

So in the previous chapter, I mentioned how Appium is a fantastic solution. However, it does definitely comes with its own caveat of being very brittle and flaky and slow, only given that additional layer that kind of envelops these native frameworks. If that is a scenario that your team cannot, kind of withheld, there are the native frameworks that are always an option for you as well to really take advantage of those more stable environments as more stable scripts that are once again more intuitive.

But the only downside is that you're actually facing this device fragmentation where you have one script to match, one framework, you have to write an additional script to match the other type of framework. So the drawbacks of Espresso. Once again, that device fragmentation is not compatible with iOS devices. You're very limited to Java and JUnit languages.

So you might be working in Ruby, you might begin to C# with your Appium scripts for Espresso. It's very more so recommended to be working in Java and JUnit languages that you might not be so familiar with. So that kind of incorporates that knowledge barrier, that knowledge gap to do just that. It is UI testing mainly, so it offers minimal solutions other than UI testing. And then although there is a test recorder offered, it's still in need of basic knowledge of how apps are built and how to create tests for solid applications.

So again, built for Android developer in mind. But that being said, it's not compatible for other applications such as your iOS applications. So speaking of iOS, that brings us to our next Native Framework XCUI test. So what XCUI test? XCUI test is a free fast native framework for UI testing on iOS mobile devices. It is baked right into Xcode ide. Just as Espresso. It does offer XCUI recorder so you can record navigation through a UI and does help create scripts.

Given that it gives the ability to find and interact with UI. Elements on an iOS application in order to validate properties and state of UI elements. So these native frameworks are two the same essentially. But one is for Android and one is for iOS. As you have the ability to inspect elements, you have those technical identifiers that might be unique to each specific native framework.

But that being said, you still are facing that device fragmentation where you might set up. You have double the scripts, you have one for Android and one for iOS. And more times than not, that isn't so, reproducible. That isn't so viable as well in your testing space.

So the pros of XCUI test, it is faster than Appium, which checks out, right? Because you're actually using the more innate framework, more making use of those unique IDs or class IDs. Given the XCUI test framework on your iOS application, so you definitely have anti-flake option for easy maintenance. Works right within your source code and very easy to integrate with your CI/CD pipeline. However, the drawback is that it's not comparable for any Android devices.

So once again, you're finding yourself double scrips. It's less stable and reliable on your devices. That anti-flake can only really benefit from when you're testing on real devices and not ideal for smoke and regression testing. So once again, kind of introduction to the native frameworks such as Espresso and XCUI Test and why Appium kind of comes into play to really envelop both those frameworks. So Appium is not a unique framework. What I mean, more or less it is, but it's once again enveloping those native frameworks.

It's enveloping the Espresso framework as well as the XCUI test framework. So you actually have one script that you can kick off. And based on those configurations, you can kick off an iOS device or you can kick off on an Android device.

So you really kind of combat the device fragmentation. So really quickly at a glance, we can see that Appium might be the best solution.

However, if you are understood that Appium can be very slow, very brittle, you might make use of those native frameworks such as Espresso or XCUI test, because once again, they do execute your scripts far faster. 

Comments are closed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}