WebDriver API for all UI automation and more

whether the UI is for desktop, mobile, web, or something else. This is a follow on post regarding these old posts:

• https://autumnator.wordpress.com/2015/01/19/webdriver-api-and-jsonwireprotocol-is-not-just-for-web-and-mobile-applications-testing-it-can-be-for-desktop-too/
• https://autumnator.wordpress.com/2013/07/12/on-contributing-to-selenium-open-source-projects/
• https://autumnator.wordpress.com/2017/10/10/cheers-to-microfocus-and-silktest-for-supporting-selenium-based-features/

It would be nice to see more UI test tooling, open source or not, to support the WebDriver API / JSONWireProtocol, so that one can use a single automation API for all UI automation, and can even do cross endpoint UI automation in a single test (one that involves both mobile + desktop + web UIs for example) by simply using a single API and multiple driver instances as needed (one for web, one for mobile, one for desktop).

There are already some per the referenced posts above, but would be nice if the open source community helps integrate/build more. For commercial test tools, until the vendor like Microfocus for SilkTest does it themselves in-house, natively, extending such support would have to be a 3rd party wrapper around the commercial tooling.

So if one is looking to help out with Selenium open source maybe consider providing WebDriver API to non-web UI test tools as a project to work on that helps you learn Selenium and other stuff at the same time. One could also make a Webdriver API wrapper to query XML and JSON, so that you can just supply XPath and JSONPath to find the element/object within XML/JSON, and load the XML/JSON with an open command but not open a browser URL but rather a file path to the XML/JSON.

This post is also a reference for myself the tools I know of where someone or myself requested for WebDriver API support/integration. I would help out myself as well if/when I had the time to do so.

• https://github.com/pywinauto/pywinauto/issues/687
• https://github.com/FlaUI/FlaUI/issues/227
• https://github.com/sdesalas/trifleJS/issues/20
• https://github.com/pyatom/pyatom/issues/154
• https://github.com/octalmage/robotjs/issues/237
• https://github.com/TestStack/White/issues/543
• https://github.com/yinkaisheng/Python-UIAutomation-for-Windows/issues/180
• https://answers.launchpad.net/sikuli/+question/234883 or https://github.com/RaiMan/SikuliX1/issues/477

Downloading older versions of Mac OS

This post will hopefully also serve as a periodically updated listing with links to older Mac OS versions for download for offline installation from image/ISO or reinstallation whether to install anew or as a way to downgrade.

It used to be that with the Mac App Store, if you downloaded the current (or new beta?) version of Mac OS, even if you delete the downloaded installer and chose not to upgrade, in the future if you ever needed it, it would be searcheable in the App Store and show up in your purchase/downloads section for re-download. You could then use various tools/scripts to generate an ISO image of the installer, etc. to deploy on DVD or a USB drive for install from boot/reboot. So the trick is to do this process for every new Mac OS release so you have it in your purchase/download history for access in future. But it seems this feature was removed in recent newer version of the App Store app. In any case, still might be useful to continue this process should this type of feature come back in the future. For your reference, this feature from what I know at least, last worked (i.e. is available) on App Store v2.4 (658.1) on Mac OS X 10.13.6 (High Sierra), and was not available on App Store v3.0 (1003.3) on Mac OS X 10.14.6 (Mojave).

As such, without that feature, it seems Apple did at least offer up some online repositories/links for getting some older versions of Mac OS X, and I list them below. If you know of additional ones that I don’t please share. I’ll update as I find more in future.

https://itunes.apple.com/us/app/macos-catalina/id1466841314?ls=1&mt=12

https://itunes.apple.com/us/app/macos-mojave/id1398502828?ls=1&mt=12

https://itunes.apple.com/us/app/macos-high-sierra/id1246284741?ls=1&mt=12

Mac OS X 10.12 (Sierra)
http://updates-http.cdn-apple.com/2019/cert/061-39476-20191023-48f365f4-0015-4c41-9f44-39d3d2aca067/InstallOS.dmg

Mac OS X 10.11 (El Capitan)
http://updates-http.cdn-apple.com/2019/cert/061-41424-20191024-218af9ec-cf50-4516-9011-228c78eda3d2/InstallMacOSX.dmg

Mac OS X 10.10 (Yosemite)
http://updates-http.cdn-apple.com/2019/cert/061-41343-20191023-02465f92-3ab5-4c92-bfe2-b725447a070d/InstallMacOSX.dmg

Update 04/20/2020:
Came across this recently, that while not a solution for all older OS X versions, might help for some: osxdaily.com/2020/04/13/how-download-full-macos-installer-terminal. Supposedly you need to be on Catalina however in order to use it.

Network (HTTP, etc.) packet capture setup across different client devices

General methods across all devices

These methods should work for all devices, for most use cases, and can be used when you can’t directly capture traffic from the device itself (unlike laptops, desktop computers).

Proxy client traffic to a host that can do packet capture

1. Have a host machine like your Mac/Windows/etc. laptop to do the capture, using wireshark/tshark/ tcpdump.
2. Use/install a proxy server on the host machine (e.g. Charles proxy on Mac, Fiddler on Windows).
3. Follow the proxy instructions to install the proxy’s SSL certificate to your client devices under test (in case you need to capture/decrypt SSL/HTTPS/WSS traffic).
4. Route/enable the client device’s (wifi) network connection to use an (HTTP) proxy, entering the values for your given proxy (the defaults or your own customized values you set on the proxy server).
5. Start proxy server on host machine.
6. Start capture on host machine.
7. Generate the desired traffic activity on client device.
8. Stop capture on host machine.
9. Stop proxy server on host machine.
10. Disable/unroute client device network traffic over the proxy.

NOTE: this probably only works provided the client traffic is based on HTTP/HTTPS/WS/WSS, where the capture will also capture the TCP/UDP packets. Not sure if it goes through other protocols whether this will work. Although most mobile devices use HTTP/HTTPS anyhow.

Shared/open network sniffing/capture

With this setup, you have a host machine like your Mac/Windows/etc. laptop or some server or Raspberri Pi to do the capture, using wireshark/tshark/ tcpdump. This host resides on a network where traffic is broadcast on all the ports (e.g. use of hub instead of switch and router, etc. at the lowest leaf level of the network where the testbed is set up) and thus said desired traffic is available to the host machine to sniff & capture.

For this simply ensure the target client to capture is in some way connected to this open sniffing/capture network, and then you can do the capture at any time as desired.

If the clients are wireless, that means the access point has to be connected to this open sniffing/capture LAN to capture the traffic.

Device specific traffic capture

iOS traffic capture

To save hassle of dealing iOS device UUID (finding it with XCode/iTunes, and then making use of it), use the script from here to wrap the process for you: https://thrysoee.dk/iospcap/.

Once that is done and the tool is started to allow capture for (USB) attached iOS device, simply use the interface(s) rviN, where N is a number starting from 0 (typically rvi0 for single device), with the capture tool (Wireshark, tshark, tcpdump). Follow the tool commands to stop the interface service after done capturing.

NOTE: this method is only for use with a Mac. For Windows, Linux, you might first need to install some software to be able to do this: https://github.com/gh2o/rvi_capture ‑ Connect your account to preview links.

Android traffic capture

There can be multiple options for traffic capture here, more especially if the client device is rooted. However, we’ll go with the simplest approach at the moment:

Use tPacketCapture app from Google Play Store.

To use the app for capture:

1. Open the app.
2. Click Capture button. Button name should change to Running, and a key-like icon will then show up in the upper/top left corner of the status bar of the device, for access to stop/disconnect the capturing.
3. Note the filename for this capture listed under “Current File” section, for reference.
4. Generate the desired traffic activity on client device.
5. Stop the capture by accessing the key-like icon at upper/top left corner of device.
   1. in the popup that appears choose disconnect (or equivalent) option.
   2. optionally kill the app to save resources, and kill whatever other apps were used for generating traffic to capture.
6. Transfer the capture file from the device to a computer for further analysis and permanent storage if desired.
   • can transfer over USB cable connection, using like Android File Transfer tool on Mac, or equivalent on Windows (which should have native file storage access over Windows Explorer).
   • can transfer over NFC
   • The capture files can be found under a path like (internal storage of Android device)/Android/data/jp.co.taosoftware.android.packetcapture/files/YYYY_MM_DD_HHMMSS.pcap.
   • you can optionally delete the files from the device afterwards to save space & for less cluster/confusion.

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.