Here is the background story:
For Mobile Automation, we want to add tests for iOS devices in an existing Android project. By modifying the elements Ids or Xpaths to match those of iOS - and changing the platform and device name in the Appium desired capabilities, we can effectively run the same tests on iOS. We use BrowserStack so that we don't need real physical devices.
In order to achieve this objective, we have several options. One is using a method representing the element, used in Page Object Models (POM) structure. You then add decorators referring to the Android or iOS path. An example might be:
@AndroidFindBy(id = "btn_signIn")
@iOSFindBy(xpath = "//UIAApplication/UIAWindow/UIAButton")
public MobileElement signInButton;
From my research, you'll have to manually switch platforms.
You can also use a type of config file such as JSON or YAML to keep the elements find by path:
And for YAML:
I am using Environment variables to switch between each platform. I only need to cater it during the Driver Setup phase.
The solution I prefer using though - is the use of a Spreadsheet to hold data - even though a CSV file can do the job. I choose this approach because it's in my opinion the cleanest one for non technical people such as testers.
Copy Paste Values
Whenever you copy and paste data, you will inevitably leave whitespaces. I first realised that several years ago after copying and pasting a password from my editor into a password input on a webpage. Yet the password didn't work. This was because the value had a trailing whitespace. The input form did not cater for this, thereby keeping the whitespace.
In my case, using the Appium Inspector, I copy the elements Xpath to the spreadsheet which usually includes line breaks and other trailing whitespaces. Once I code my logic and test it well, I note that for a particular element, the value does not match. Even when I log it, the value is completely similar. I spend several minutes trying to understand what is wrong; but even more intriguing from a debugging perspective, I assume that the problem might be with the element path values. I check every value once again - copy paste - yet arrive to the same conclusion.
I change my approach by directly hardcoding the value and it works as expected. I immediately know what the issue is. Without spending further time checking my spreadsheets, I add trim method to the string values that are read. And sure enough, the logic works.
So if tomorrow someone else works on extending the elements path values, even if they leave trailing whitespaces, the code now caters for this behaviour.