Appium Notes
Important note on React Native apps
React Native apps can indeed be automated using Appium.
Remember, React Native apps are native apps, not hybrids. For example, the Sauce Lab
demo app we use in this course is a React Native app.
If you're working on automating a React Native app and struggle to find unique UI
elements, request your developers to add a "testID" attribute for each UI element. This
attribute corresponds to resource-id (or content-desc ) for Android and
accessibility-identifier (or label ) for iOS. Developers may be reluctant to add
an "accessibilityLabel" attribute as it can interfere with accessibility reading tools.
However, with "testID," you can circumvent this issue. It’s possible to have both
"accessibilityLabel" and "testID" if your developer consents.
If you manage to achieve this, you’ll likely not need XPath in most cases, making your
life much easier. Take my word for it.
Important note on Flutter apps
I'm getting a lot of queries around Flutter app support. Unfortunately, the current
options to automate Flutter-based apps are limited, and each option has some pros and
some cons. So, please go through the below options and evaluate them as per your
project requirements.
Option 1: Appium's UiAutomator2/XCUITest driver
Appium's traditional drivers, UIAutomator2 for Android and XCUITest for iOS, can be
used to automate Flutter-based applications. However, you may observe issues while
using these drivers. The primary issue is that many UI elements are not identifiable
using their attributes. Many times, long, fragile XPath has to be used. This is because all
the element attributes used for UI elements in the Flutter app may not be visible to
Appium's UiAutomator2 or XCUITest driver. So, if you plan to use these drivers, please
try to build optimised XPaths using axes and other XPath features. This way, the tests
will be less flaky.
Option 2: Appium's Flutter Driver
Appium has a Flutter driver that may solve the above issue, but it is still in the
experimental phase. Here's the GitHub link for the
driver: [Link]
With this driver, you may be able to use Flutter's element attributes to find the
elements. Since this is still in the experimental phase, you may observe other issues or
there may be some limitations. Please do a small POC and see if this works for you.
Here's the Flutter element attributes
list: [Link]
You can work with your developers to get the unique attributes added so that those are
visible to the Appium's Flutter driver.
Option 3: Flutter's Flutter Driver
Flutter has its own driver for automating Flutter apps. It's called the "Flutter driver", but
it only supports the Dart language, which can be alien to many of us. The good thing is
that it can be used for integration testing. However, there could still be some limitations
around what end-to-end scenarios you can automate. Here's the link to the official
documentation: [Link]
If you prefer, you can use this driver to automate your app. Please consult with your
developer and the team before deciding on using this driver. You may have to spend
some time learning the Dart programming language before you can use this driver.
Option 4: Maestro
There is one emerging no-code tool called Maestro that supports Flutter apps.
Currently, it supports only emulators and simulators. You might want to check it out
here: [Link]
I have heard good things about this tool. Also, note that it's purely a no-code tool and
doesn't use any underlying framework like Appium to interact with the UI. In a way, this
is a good thing, as it doesn't have all the limitations that Appium has when it comes to
finding UI elements and also the overall speed of execution.
At this point, I do not have any recommendations on which driver to use for Flutter
apps. Use whichever works for you. You will need to talk with your developer or team
and decide on this.
Important note on OTPs (MFA)
Important note on OTPs (MFA)
I keep receiving queries on how to automate SMS-based OTPs. Here are five methods
to handle OTPs (MFA):
1. Remove the OTP requirement for test accounts and test environments.
2. Allow static OTP for test accounts and test environments.
3. Retrieve the OTP from the database or via an API. Although there may be security
concerns, it is still worth attempting in test environments.
4. If your app sends OTPs via email, programmatically fetch them by accessing the
user's email.
5. Fetch the OTP from the real mobile device.
Many opt for option 5, primarily because they lack the necessary support from their
team for options 1, 2, and 3, and when option 4 is not feasible.
Some believe that automating OTPs through the mobile UI is straightforward, but this is
not the case!
Option 5 should be the least desirable.
Why? Let's delve into the details.
The backend notification service typically generates and validates the OTP. The app's
UI's sole function is to receive the OTP from the user and send it to the backend API.
Therefore, we should only validate this functionality through the UI. For this purpose,
any OTP that the app accepts is sufficient. How the OTP is generated does not
significantly impact the app.
The process of generating and validating the OTP can be automated through API
channels or lower-level automation, such as component tests or unit tests.
The notification service creates the OTP and sends it to the network carrier (or mobile
service provider), which then triggers the actual SMS. The SMS traverses the network
to reach your device, where the messaging app receives and stores it. Automating this
functionality is unnecessary, as it falls outside the app's scope. The app is not
accountable if the mobile service provider fails to deliver the SMS or if the device fails
to receive it. These functionalities should be tested separately through other
integration-level tests.
Fetching the OTP from the device is ill-advised for several reasons:
• This process is unrelated to your app's core functionality.
• It binds your test account to your specific device.
• It is unreliable and prone to frequent failures.
• Different implementations are necessary for iOS and Android, and even within
Android, variations may exist depending on the mobile OEM.
Therefore, think carefully before choosing option 5. In my opinion, options 1, 2, and 3
are more suitable for handling SMS OTPs. Additionally, if your OTPs are sent via email
(option 4), consider this method for fetching the OTP, as it is relatively reliable and
straightforward.