using same interface for IOS and ANDROID Elements

[alizelzele]

I was wondering if there is any specific reason that you separate android and ios platform's Elements from each other? why not using the same interface for both of them, with some specific functions on each of them; and using interfaces names in yaml files?

Maybe a yaml reader version 3 will be required to handle different locators for each platform in each specific languages? Usually you want to test the app in both android and ios and they are almost the same style and design, why not use the same script for testing them?

[mach6]

Hi @alizelzele,

SeLion's ios and android elements are modeled after Apple's support in UI Automation and Google's support in uiautomator.

See;

• https://developer.android.com/reference/android/support/test/uiautomator/UiObject.html
• https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Reference/UIAutomationRef/index.html

I understand your concerns w.r.t testing across platforms and share the desire to have a solution which minimizes the amount of PageYaml, etc that would need to be created. If you would like to propose a change to the existing code in the form of pull request here, we'd be happy to vet it / take it into consideration.

Cheers!

[mach6]

@alizelzele closing this github issue for now. Please re-open if you have further questions or see a need to. Please also feel free to ask questions via our Google group and Gitter channel

[alizelzele]

Hi @mach6 ,

I think this design aligns with the Appium principle and is required for testers cause they usually have to test the same application on both Android and IOS.

To implement this feature, we need to have below changes:

1. Create mobile elements interfaces, and make the existing elements of Android & iOS implement it.
2. code generator.
   a) new template files support new interfaces and create correct instances on runtime.
   b) yaml reader for new yaml page files

HERE is sample change for what I meant to implement.
Appreciate if you can review and give your opinion, or any change can make it better or more usable?

[mach6]

@kumaravel-jayakumar I would appreciate your feedback here.

[renelux]

To be able to support this we would have to create separate yaml reader and page implementation to support mobile. Wouldn't it be possible to support this feature through custom elements? This way it could be made into a module where the end user can decide if they want to use it or not.

In the end the fact that you need to test both apps and that the app are very similar is not necessarily true. In fact if an app follows the style guide of each platform there could already be quite a big difference.

[alizelzele]

@renelux
if we want to do this with custom elements, we will face the problem again with multi platforms and separate page objects cause that is how selion behaves right now.

I was thinking the exact same way on the start about style guide of each platform and so, but after checking some of the applications, i find out that they are usually behaving the same way and there is not a big difference as i was expecting to be there.

Since i am keeping the compatibility with older version, every thing can be defined the exact same way as before. If anybody wants to use a common page object for both platforms, he can benefit from an already existing solution for that.

[mach6]

Hi @renelux my first inclination too was to propose a custom element. While I think it would be possible to some extent, it could get messy w.r.t the locators for the custom element in the PageYAML.. One would have to introduce their own parsing logic in each custom element to identify the part of the locator to be considered for platform=android and the part to be considered for platform=ios. So, long story short, I think @alizelzele raises a good point and it would be nice if SeLion had some level of support for this use case.

@alizelzele I'm sorry for my delay in replying. I took a brief look in your current progress and overall I feel you are heading in a good direction. There might be parts where change will be proposed once you submit a PR, but at this point I don't have any suggestions. Is there a particular part of the pending implementation that you want direct feedback on?

[mach6]

And BTW.. Thank you for taking this change on! :)

[alizelzele]

@mach6 I was wondering about the way the page-yaml-file should be and how to parse it (using a new reader or extending the existing one), but i think i found the best way to do it i will change it a bit more and create a PR.

[ken-jiang]

@mach6 the code for this is almost done. Will you create a patch branch for testing and review? or @alizelzele submits the pull request to develop branch?

[mach6]

Hi @ken-jiang the contribution approach is documented in our https://github.com/paypal/SeLion/blob/develop/README.md

Yes, in this case a pull request to the develop branch is what we need.

Once submitted, it will trigger the CI build for the pending PR and a review -- which will be conducted by myself, other project admins such as @sebady and @sundaramrajendran, and anyone else in the community that is interested.

Also, if applicable (only PayPal employees are exempt), a contributor must sign the CLA.

[kumaravel-jayakumar]

@alizelzele

Sorry for my delayed response. I really appreciate your work and contribution towards SeLion. To answer you initial question "I was wondering ... specific reason ... separate android and ios platform's Elements " over @mach6 reply. iOS test automation engineers (coming from Javascript) are familiar with a unique set of widgets and gestures (UIAElement, UIAButton & tap(), doubleTap(), dragInsideWithOptions()) whereas Android engineers (UiObject primarily & click(), clickBottomRight(), dragTo()). Though they have some commonalities between them they were not similar, so in order for them to easily on-board and have a seamless transition we had to give them a similar set of widgets and methods (naming and behaviors) as their native technology. This was the prime reason they were designed separate.

There could also be (now) or may be tomorrow that one technology (iOS/Android) has a separate widget that the other does not support. This can be said for gestures also. So putting them under a same hierarchical structure could void certain implementations.

The gestures may imply the same action but called tap in iOS but in Android its was named as click. So we did not want to choose either one as a common name preferring one technology over the other. So we decided to go separate ways.

Another point was what if I have a similar widget in both technology and a gesture that is possible in one technology and not the other. Like say if there is some gesture called "scratch" in iOS button and Android Button cannot be "scratched"?

These were the points thought out before designing them as separate hierarchy of models. But I understand and appreciate that there are commonality between the widgets and appreciate you work to unify them.