Tag Archives: WebDriver

Announcing free Microsoft Edge testing in partnership with BrowserStack

Today, we’re thrilled to announce a partnership with BrowserStack, a leader in mobile and web testing, to provide remote virtual testing on Microsoft Edge for free. Until now, developers who need to test against a specific version of Microsoft Edge have been limited to local virtual machines, or PCs with Windows 10 installed. However, there are many developers that don’t have easy access to Microsoft Edge for testing purposes.

Screen capture showing Microsoft Edge running inside a browser on macOS.

BrowserStack Live Testing can run Microsoft Edge inside your browser on macOS, Windows, or Linux.

Today, we are excited to partner with BrowserStack, which provides the industry’s fastest testing on physical devices and browsers, so that you can focus on delivering customers the best version of your product or website. BrowserStack is trusted by developers at over 36,000 companies, including Microsoft, to help make the testing process faster and more accessible. Under this new partnership, developers will be able to sign into BrowserStack and test Microsoft Edge using their Live and Automate services for free.

Live testing provides a remote, cloud-based instance of Microsoft Edge streamed over the web. You can interact with the cloud-based browser just as you would an installed browser, within your local browser on any platform – whether it’s macOS, Linux, or older versions of Windows.

As testing setups are becoming more automated, we are excited to also offer BrowserStack’s Automate testing service under this partnership, for free. This method of testing allows you to run up to 10 Microsoft Edge test sessions via script, which can integrate with your local test runners via the standardized WebDriver API. You can even configure your machine so that the cloud-based browser can see your local development environment—see the Local Testing instructions at BrowserStack to learn more.


Testing Microsoft Edge in BrowserStack using WebDriver automation

To ensure you can test against all possible versions of Microsoft Edge that your users may be using, BrowserStack will be providing three versions of Microsoft Edge for testing: the two most recent “Stable” channel releases, and the most recent “Preview” release (via the Windows Insider Preview Fast ring).

You can test Microsoft Edge on the Windows 10 Anniversary Update (EdgeHTML 14) starting today. EdgeHTML 15 will be available in the Windows 10 Creators Update starting on April 11, 2017, and will come to BrowserStack in the following weeks.

BrowserStack currently serves more than 36,000 companies globally including Microsoft, AirBnB, and MasterCard. In addition to Microsoft Edge, the service provides more than 1100 combinations of operating systems and browsers and its Real Device Cloud allows anyone, anywhere to test their website on a physical Android or iOS device. With data centers located around the world, BrowserStack is trusted by over 1.6 million developers relying upon the service as it provides the fastest and most accurate testing on physical devices.

We’re very excited to partner with BrowserStack to make this testing service free for Microsoft Edge. Head over to BrowserStack and sign up to get started testing your site in Microsoft Edge today.

― Jason Weber, Director of Program Management, Microsoft Edge

Windows Application Driver for PC integrates with Appium

The most time consuming and expensive part of developing an app is often the testing phase. Manually testing an app on hundreds of different devices is impractical, and existing automation solutions run into a number of platform and tooling limitations. Appium is designed to simplify testing by supporting multiple platforms, and it’s our goal at Microsoft with Windows Application Driver (WinAppDriver) to enable you to use Appium to test Windows apps. The recent release of Appium v1.6 integrates WinAppDriver so developers can run tests targeting Windows 10 PC applications through Appium!

What is WinAppDriver?

WinAppDriver is a modern, standards-based UI test automation service that aligns with the Selenium WebDriver Protocol The Windows Application Driver allows a developer to use the “write a test once, run anywhere” approach. No longer forced to choose a specific test language and runner, developers are granted flexibility and no longer need to rewrite tests for each platform.

What is Selenium/Appium?

Selenium is the industry standard for automated UI testing of websites/browser applications. Selenium works off of the WebDriver protocol, which is an open API for browser automation. Realizing that this same protocol could be leveraged for mobile app UI testing, the Appium project was created, and it extended the WebDriver API to allow for app-specific automation endpoints. WinAppDriver was created in the spirit of the Selenium/Appium projects to conform to the industry standards for UI testing and bring those standards to the Universal Windows Platform.

How it works

screen-shot-2016-11-15-at-5-12-47-pm

With Appium’s integration of WinAppDriver, developers will have full customization of their preferred testing language and test runner as shown in the diagram above—and they can reuse their tests if their app is on iOS and Android. It is only through Appium that developers can have this customization – each UWP developer might prefer a different test script/test runner for their UI tests and because Appium uses the Webdriver protocol, developers can have that flexibility when authoring tests.

What about CodedUI?

The current UI test automation solution for Windows app testing is CodedUI; however, Coded UI only works for apps running on the Windows platform. For developers who write cross-platform apps, this means they have to write tests for each platform they are targeting. Additionally, those developers who write cross-platform apps will have to write custom tests for each platform they are targeting.

With Appium supporting multiple platforms like Android and iOS, Microsoft encourages customers to use Selenium and Appium for Functional UI testing.

How can I get started?

To download Appium with Windows 10 PC support, make sure you have Node version >=6.0 and npm version >=3.5. Then use the following steps:

  1. In your command prompt, run npm install –g appium
  2. Then, run the command appium from an elevated command prompt
    1. Make sure developer mode is on as well
  3. Choose a test runner (Visual Studio, IntelliJ, Sublime Text etc.) and a language to test in (C#, Ruby, Python, etc.)
  4. Create a test targeting a Windows application of your choice.
    1. Set the URL targeting your Appium server, and the appId capability set to the app ID of the app you are testing.
    2. The platformName capability should be set to “Windows” and the deviceName capability set to “WindowsPC” in the test script.
  5. Run your test from the test runner targeting the Appium server URL

Here is a screenshot of what the install process looks like from the command line:

picture1

As part of the install, you should see that WinAppDriver is downloaded and successfully installed:

picture2

Then, just run Appium from the command line:

picture3

Now that the Appium server is running, you can run a test from your choice of test runner pointing to the Appium endpoint. In this example, we’ll use a test targeting the built-in Calculator app on Windows 10.

picture4

The key components (shown in the red boxes) are setting the URL to target the Appium server, as well as setting the app ID, platformName and deviceName as explained in the earlier instructions.
Once you run the test, you should see results in the test runner.

picture5

To see sample tests, check out the sample apps/tests on the WinAppDriver Github page or in the Appium samples repo. For more information about WinAppDriver + Appium, visit Appium’s website or their GitHub, or check out these videos talking about how Appium and UI test automation works.

Panel with Jonathan Lipps from SauceLabs
UI Test Automation for Browsers and Apps Using the WebDriver Standard

Ensuring high-quality browser accessibility with automation

Over the past few weeks, we’ve shown how Microsoft Edge has been rearchitected to empower developers to build more accessible experiences on the Web with HTML5 and UIA. To support this work, we need to ensure that accessibility is not accidentally regressed as we make other improvements to the browser.

Testing the accessibility implementation of a browser on Windows used to require downloading the tools for the browser you wanted to test and then manually checking each of the requirements of a test suite. To help reduce this overhead, and to ensure we catch regressions before they ship, we created a tool to automate the HTML 5 Accessibility test suite .

What is necessary to automate accessibility

In order to fully test accessibility, you need to not only test the platform to ensure your code is working as expected, but also the bridges between the UIA client and the UIA provider. In order to accomplish this, we built a custom UIA client to iterate over the tests of HTML 5 Accessibility by requesting nodes from the accessibility tree via web driver automation.

The figure below shows the accessibility pipeline from the page source to the user. An HTML element, such as the video element, is converted by Microsoft Edge or another browser into several UI Automation Elements. The video element is the parent of the other elements, which represent the controls, such as the play button or volume slider. Then an assistive technology, such as Narrator, communicates those elements in a way the user can understand, for example by speaking their names aloud. Our automation took the place of the accessibility tool to verify that the rest of the pipeline was working correctly.

Chart showing the accessibility pipeline from the page source to the user. HTML elements are converted into UI Automation elements, which are relayed to assistive technology to be communicated to the user.

Automating the HTML 5 Accessibility tests

Automating these tests requires two types of access to the page. First, we need to be able to simulate user input, such as key presses, which we do through WebDriver. Second, we need to verify that the content of the page is accessible to users of all abilities, which we do through accessibility APIs, such as UI Automation.

It’s important to understand that the DOM tree and the accessibility tree have two different sets of elements, which don’t always have a one-to-one relationship. For example, the video element might not have any children in the DOM tree, but will have several children in the accessibility tree.

First, we walk the accessibility tree to ensure that the element can be found on the page and that it has the right control type. Next, we use WebDriver to tab through all the keyboard-accessible elements. This is important because the web is often a difficult place for keyboard-only users we want them to be able to navigate all sites and access all elements.

Accessibility on Windows goes beyond Microsoft Edge

The work we’ve done has helped us improve accessibility in Microsoft Edge, but we want all users on Windows to have a remarkable accessibility experience, no matter what browser they’re using. To accomplish this, web developers need to ensure their sites are accessible and other browser vendors need to ensure their browsers meet accessibility requirements. To help the community in this endeavor, we are open sourcing our HTML 5 Accessibility test harness code on Github with a MIT license.

As a part of this project, we’ve included a sample branch to help web developers begin to automate accessibility testing of their own sites on browsers that utilize UI Automation clients. You can use it on your site by specifying the URLs you want to test and what needs to be tested on each site. You can learn more about how to test your own site by looking at the site automation readme.

We hope this can be useful to help make your products work for everyone, and we look forward to feedback and contributions from the community!

– David Brett, Software Engineer
– Greg Whitworth, Program Manager

Bringing automated testing to Microsoft Edge through WebDriver

Today we’re announcing support for automated testing of Microsoft Edge through the W3C WebDriver standard. To use WebDriver with Microsoft Edge, you need the MicrosoftWebDriver server on a Windows Insiders build of 10240 or newer. Once that’s installed, you can try out WebDriver for yourself!

WebDriver is an emerging standard through which Web developers can write tests to automate Web browsers for site testing. It provides a programmable remote control for developing complex user scenarios and running them in an automated fashion against your website in a browser. WebDriver is used by top web properties like Bing, Azure, SharePoint, Facebook, Google, and others to automate testing their sites within a browser. With this new capability, Microsoft Edge can be run through the same regression testing as other browsers, helping developers identify issues with less effort and making sites just work for our end users.

As we described in “Building a more interoperable Web with Microsoft Edge,” the Web is built on the principle of multiple independent, interoperable implementations of web standards, and true interoperability means that all web content, browsers, and specifications should align to the same well-defined behavior. Keeping that principle in mind, our implementation supports both the W3C WebDriver specification and the JSON Wire Protocol. The Browser Testing and Tools working group has been doing a great job of standardizing automation testing interfaces as a part of the emerging WebDriver specification. For backwards compatibility with existing tests, we have implemented the JSON Wire Protocol, so existing tests should also just work. We’re not done yet, as the WebDriver specification is still in an early stage of standardization, and we still have more features to implement. You can find out more about all of the WebDriver interfaces we have implemented on our Platform Status page here.

Borland contributions to Microsoft Edge

MicroFocus Borland logoMicrosoft has a long history of collaborating with industry technology leaders to bring the best-in-class experiences. In order to truly build an interoperable implementation that our customers can use, we have partnered with the Borland Silk team from Micro Focus, an industry leader in automation testing tools, to help contribute code to the WebDriver implementation in Microsoft Edge. The Borland team is also bringing their expertise in automation testing to help inform the next level of changes we should pursue in the W3C standard. Our thanks to the Borland team for all of their help in making the Web better!

How WebDriver works

To get started using WebDriver, you will need to download a testing framework of your choice along with an appropriate language binding and the MicrosoftWebDriver server. We have submitted updates to the C# and Java Selenium language bindings and are hoping to add support to other languages in the future.

WebDriver is disabled by default for security. In order to enable using WebDriver, you will need to download and install the MicrosoftWebDriver in a location with your test repository. You should be able to use Microsoft Edge’s WebDriver implementation just like you would use any other browser’s implementation.

Diagram of WebDriver and Microsoft Edge

Here’s an example of C# code opening a new browser Window, navigating to http://www.bing.com and searching webdriver.

.gist table { margin-bottom: 0; }

We’re excited to deliver WebDriver in Microsoft Edge and look forward to hearing what you think! Take it for a spin and share your feedback in the comments below or @MSEdgeDev on Twitter.

Clay Martin, Program Manager, Microsoft Edge
John Jansen, Principal Software Engineer, Microsoft Edge
Jatinder Mann, Senior Program Manager Lead, Microsoft Edge
– Mark Conway, Director, Micro Focus