Make a good suggestion (to open source) and things will come

Post a bit delayed compared to a recent mobile automation feature release, as I’ve been busy. But wanted to mention about this. And also relevant to those who ask how they can help/contribute to open source. Sometimes, all it takes is a good idea/suggestion.

Long time back, I made a suggestion to Appium project about being able to have additional “find element by” logic using images, similar to what Sikuli does, and suggested how the implemented command may be used by a user. It was put under consideration, and recently implemented.

The original request: https://github.com/appium/appium/issues/943

And article about the recent implementation: https://appiumpro.com/editions/32

Uninstall old SafariDriver on recent versions of Safari

Aside from not needing SafariDriver starting in Safari 10 (or was it 9? I forget) and requiring recent versions of Selenium with older versions of Selenium paired with older Safari using SafariDriver, if you’re like me and haven’t used Selenium/SafariDriver in a while, you might have left the browser with SafariDriver extension.

If you update Mac OS X and Safari, you may still have the extension installed unless you specifically uninstall it.

One interesting quirk about having it installed is that it can now cause problems on certain websites (likely from same core issue from something in the extension’s codebase):

TypeError: Value is not a sequence

This came up for the websites from my company as well as Apple’s iCloud.com.

Once I uninstalled the extension, everything was fine.

Awesome Stuff – Selenium, RobotFramework, test automation, etc.

A while back I came across the “awesome” series of listings of (good?) resources for a given category (awesome go/java/ruby/python/etc.).

Well, it’s nice that it has expanded to other areas beyond programming languages, and per se to my original blog content, some areas I and my readers are interested in that I thought to share (if you haven’t already come across them):

• https://github.com/christian-bromann/awesome-selenium
• https://github.com/fkromer/awesome-robotframework
• https://github.com/atinfo/awesome-test-automation

I’m contributing to these as I can. And we all should, but at the same time, in keeping with the motto “awesome”, entries in the list should have good reason to be there, not just “yet another related thing to put on the list”, should be something special, otherwise, it will end up a bloated list of (spam-y) stuff.

Cheers to Microfocus and SilkTest for supporting Selenium-based features!

In particular, I’m most intrigued by them offering support/integration with WebDriver API access to SilkTest. That means automating with SilkTest using WebDriver APIs (via a tool called SilkAppDriver) in your language of choice, not running Selenium tests through SilkTest IDE/code, although I’m sure the latter is supported in some way.

WebDriver API is a W3C specification, and it’s great if we can get more applicable tools to use that protocol to drive (G)UI automation than to have different proprietary languages, frameworks to for each tooling vendor. Say for example, you can switch out your home access point or router and your network still works the same as they speak same protocol. Shouldn’t have to be a pain to switch out test automation tools either, the dreaded vendor lock-in.

And Microfocus also has a nice improvement over Selenium IDE as well: Silk WebDriver.

Now if only other (commercial) test automation tool vendors could follow suit.

NOTE: on a related note, I hope to see (more) variants of SilkAppDriver for the free and open source non-browser/mobile automation tools (since we have Selenium WebDriver and Appium/Selenoid for those already). We currently have these in the free/open source space: AutoItDriverServer, AutoPyDriverServer.

Update 01/26/2018: I just came across Ranorex Selocity, a Firebug/FirePath/Firefinder replacment, but for Chrome instead of Firefox. Cheers to Ranorex for offering such a tool. Now I hope they follow on with their equivalent to SilkAppDriver, and perhaps especially Silk WebDriver since Selocity is closer to the latter than the former, but I personally prefer more options of the former.

On filing bugs to Apple

Unlike other public bug tracking systems, Apple’s one is closed to public viewing other than Apple and the reporter of the bug.

So bugs you report, others can’t see the status of. And as such, there can be likelihood of duplicate bugs being filed, etc. I assume Apple has good reasons to overlook potential duplicate bugs in favor of this closed access bug tracking system.

Amusingly, a public repository of Apple bugs is available at OpenRadar. It’s useful for the public community to look for existing bugs filed to Apple before filing their own, and check status of said bugs. There is one caveat though, OpenRadar does not pull data from Apple’s system. Therefore to get data into OpenRadar, one must file a “duplicate” bug to it for whatever one files to Apple.

As such, I would recommend those of us who deal with Apple bugs to:

1. Check OpenRadar first before filing bug to Apple. If one exists on OpenRadar, just subscribe to and monitor that. Although one is free to file a duplicate to Apple just in case.
2. If one doesn’t exist on OpenRadar, then file bug to Apple. And if the bug is not specific to your internal case (confidential/security/proprietary info, intellectual property, etc.), post a duplicate filing on OpenRadar. This allows the public to see the bug you filed. Also makes it easier for team members to view the bug for those teams that don’t use a shared/team Apple developer account or whose said accounts aren’t all under the same organization access. NOTE: that if you file a duplicate post on OpenRadar, do try to keep it updated or in sync with changes/updates on the official bug you have with Apple, so the public knows the status of it.

UI test automation of virtual app/browser delivery to local desktop

This thought just came to mind as I read through forum posts recently regarding automation scenarios like the following:

• a web app or site is delivered to the user via a browser presented within a browser. e.g. via Citrix virtualization solutions delivered over a browser for desktop & browser-based apps.
• a web or desktop app delivered to the user remotely via virtualization but made to feel as if it was installed, running, and deployed locally on the local machine, delivered via tools like MS Application Virtualization Client, Citrix, etc.

How do we test for these apps/cases, particularly say if we wanted to test against the exact deployment setup of how they are used? It would seem from the current infrastructure, this is likely a manual testing activity. And for automated testing, we are relegated to simplifying the test setup and assuming the simplified setup will behave the same as actual deployment, and just cover any differences with manual testing.

I bring this up as I know not of any existing automation solutions, commercial or free/open source, but particularly the latter, where these kinds of special deployment setups are supported for automation testing. As these deployments are delivered through virtualization technology, unless the test automation tools are integrated in that virtualization delivery (e.g. hosted and running in the same context as the app that’s delivered over virtualization rather than locally on the client receiving the virtualized app), the test tools won’t be able to detect and automate the virtual app. That integration is likely not feasible or easy to do due to platform isolation and security restrictions and sandboxing. It’s not quite the same as just running everything (the app under test & the automation tools) on a remote host and accessing it via remote desktop/VNC to see it in action.

Perhaps this isn’t much a concern for the community/industry until more and more people use this type of app delivery infrastructure where it is ubiquitous like mobile devices/apps are today. Still, something to ponder about for the future of testing. Wonder what is to come in this space for test automation. Or have I just been ignorant and we already have some tooling for this today?

A page object representing both desktop and mobile views or website and mobile app

It just occurred to me today, from reading a Selenium forum post, that a past blog post of mine can also apply to the following cases:

• you have both desktop and mobile views for a website or web app (e.g. responsive design, etc.)
• you have a website and a native mobile app that offers similar service/functionality

and as such in both these cases there is shared logic (user/app/site workflow, element locators – even if the actual values differ, but the “logical” representation is the same such as login button on both web site and mobile app, etc.).

Using the techniques defined in that other post, you can share locator references/variables and share page object methods and have a single page object represent both mobile & web versions. For sharing of methods with branching logic, instead of checking which A/B flow to go through, you check what platform you’re on and go to appropriate branch logic based on that.

Also on some specifics, I haven’t tested this type of implementation before, but in theory should work out even for cases where you have website and a native mobile app:

• You just have to use the right driver instance in the page object methods (or instantiate the page object with the right driver instance), etc. based on the platform (e.g. Appium/ios-driver/etc. vs Selenium WebDriver).
• For shared locators, XPath may work best, using the multi-valued locator approach with pipes “|”. That is because I know Appium (at least) supports XPath based locators. Not sure about CSS selectors. So, I’m hoping/assuming Appium supports the multi-valued XPath functionality. Don’t know about the other tools lke ios-driver, etc. If this doesn’t work out, you would need separate locator references/variables then.

Some of you might not agree, but this is one way to do it with code reuse via some manageable complexity. The alternative is to have separate page objects with separate methods and locators. That keeps things simpler but give you extra files, extra code, and some redundancy when some of that code and locators are kind of similar. In the end of course, choose whatever works best for you.