Using C# to automate web application testing in Edge with WebDriver

More and more applications are being built on web technologies, from familiar web apps and services, to Electron-hosted JavaScript, to a new generation of stand-alone progressive web applications. The underlying family of HTML 5 technologies, including JavaScript and CSS along with transpiled languages such as TypeScript, have matured and are delivering far more than we expected in the early days of the web.

The modern web has almost all the tools we need to deliver reliable, enterprise-grade applications. We can build code in familiar IDEs; we can debug it using browser-based tools such as those waiting behind F12. There are even linters to guide us to writing better code. But one area still lags: testing.

Introducing WebDriver and Selenium

Automated web testing tools have been around for a couple of decades now, initially co-opting browser engines to give us headless tools that used the page document object model to automate form filing and parsing results. Early tools were able to simulate user interactions at scale, giving us a tool that not only helped show whether pages and applications performed as expected, but showed how sites performed under load, an essential part of web application testing that was hard to do without automation.

Modern web application testing builds on those tried and tested techniques, though instead of simulating browsers and users, they now build on the Selenium project’s original WebDriver specification to test out interactions with production browsers, such as Firefox, Chrome, and both the old EdgeHTML and the new Chromium-based Edge. Microsoft announced support for WebDriver in the new Edge last year at Ignite.

The WebDriver API is currently on track to become a World Wide Web Consortium standard, with a working draft specification in place. Edited by representatives from Apple and BrowserStack, it’s intended to codify Selenium’s approach to browser automation and application testing, taking advantage of wide community and industry support for Selenium and its long history as an open source project.

With WebDriver you can write code to control a browser directly, with your test scripts simulating user interactions. It’s worth considering using WebDriver over JavaScript tests, as you get greater coverage of browser actions, working across tabs and windows while simulating events from both users and the underlying operating system.

Edge and WebDriver

You do need a different driver for each release of Edge. This allows you to test the release version of Edge alongside the Neta, Dev, and Canary releases. Running tests across release and prerelease versions can help you isolate browser-specific bugs or tune pages and applications for new browser features without affecting normal operations. Microsoft provides a library of WebDriver implementations for both the Chromium release and legacy EdgeHTML.

Once you have installed the appropriate WebDriver for your version of Edge, install a language binding from the Selenium site. There are versions for most common languages, from scripting languages such as Ruby, to popular enterprise languages such as Java. Selenium provides a useful Chrome plug-in (that works in the new Edge) that you can use to collect and play back interactions, building and testing simple scripts.

Using WebDriver with C#

The C# WebDriver gives you .NET bindings for the API calls, letting you build and run your own test scripts without having to stand up an instance of the Selenium server. You can download it from NuGet as well as from the Selenium site, which simplifies including it in your Visual Studio projects and solutions. It’s a good idea to make your C#-based tests part of the same project as your web application, so you can be developing ASP.NET Core in parallel with the WebDriver tests that will be used for both unit and acceptance tests. Other installation options include using the Chocolatey package manager or a preconfigured Docker container with Edge and the Edge WebDriver installed and running.

Microsoft currently recommends using the in-development Selenium 4.00, which has public alpha builds, as it has built-in support for the new Chromium Edge. Older versions, including the stable Selenium 3 still work, with the appropriate language bindings. You do need to make sure you have the appropriate version installed for your Selenium release. Recent releases of WebDriver and Edge have changed the code needed to enable WebDriver from ChromeOptions to EdgeOptions. Older versions of your tests won’t work if you’re using them against Edge 80 or later without making the appropriate changes.

If you’re using an older version of Selenium you can still use it with the Chromium version of Edge, though it defaults to the legacy version of EdgeHTML unless you set the UseChromium property of EdgeOptions to true. You can then target specific binaries, a useful option if you have multiple versions of Edge installed on your development PCs. Once you’ve set WebDriver to use the latest Edge, you’re able to use Selenium with specific Chromium features; for example, you can run Edge in headless mode to test web crawlers or REST APIs.

The WebDriver API is complex, with a lot of functions and a steep learning curve. You may find it easiest to use the Selenium IDE browser plug-in to generate basic scripts for your tests, and then take those scripts and use them as the basis of your own code. Even then it’s a good idea to spend some time understanding how the API works before translating your saved scripts into C# code.

Using WebDriver with Visual Studio testing tools

In practice much of your test code will depend on well-structured HTML and CSS, for example using element labels to navigate to forms and then fill in details. Good web design practice will make it a lot easier to automate testing your sites and content, so ensure that you’re labelling your ASP.NET elements. If you’re testing against a site you didn’t write, use the F12 tools in Edge to get the element names and then use them in your scripts.

WebDriver isn’t only a tool for navigating content; you can interact with it, sending content to form fields, picking elements, and then interacting with buttons and other navigation features. Interaction scripts can then be wrapped as test cases, with pass and fail conditions, ready for use with familiar tools such as NUnit. With NUnit you can make your tests part of a Visual Studio build. You’re not limited to an IDE; bundling WebDriver tests into Azure Pipelines or into GitHub Actions can help ensure that code is tested before it’s pushed to production or before a pull request is accepted and new code is merged with a branch.

Testing is a key element of any development process, even web application development. By automating Edge interactions with Selenium and WebDriver, we’re able to work within a test framework that uses actual browser features, allowing us to build tests at the same time as code and make them part of our software development lifecycle.