If you’ve never done automated UI testing of your web apps, you’re in for a real treat! You can visit your pages, click buttons, verify results, take image snapshots, all automatically through code. Your code actually controls a web browser that interacts with your site. I’ve recently rediscovered its benefits and am vowing to up my UI testing game. Why? Better code through testing. I’m not necessarily all in on Test Driven Development, but I’m after a certain set of results. I want my tests to eventually do my thinking for me. I can’t possibly remember all the little things I want to validate in every web app I write (many of them). All the business logic, widgets, rules, and customized niche stuff. Best of all, its super easy in your ASP.NET MVC apps using MS Test and Selenium Webdriver. This post will walk you through setting up your test code in your web solution, then executing that test as part of a build definition in Azure DevOps (formerly Visual Studio Online/ Visual Studio Team Services). This last part, executing the tests in the cloud, is the best part. Its hands free, automatic, all web based. The results are easy to track for someone who can be a little disorganized at times. I have a complete history of each test execution stored online all in the same place I live anyway, in Azure DevOps.
Get Started Writing Your UI Tests
UI testing is a vast universe of many wonders of which I’m not going to cover for this post. You will see the most basic of unit tests here. First, in Visual Studio, add a new project to your web app solution. In the left menu, select .Net Core if you’re building a .Net Core web app, select Test if you’re building for .Net Framework. In the middle pane, select the Unit Test Project option. You’re unit test project will be added.
In your unit test project, add the Selenium Web Driver, and Selenium Web Driver Chrome Driver (or Firefox) Nuget packages. The Selenium main package is responsible for core UI testing while the browser driver packages interface with the browser of your choice.
Your first test class is added automatically to the project. The test class itself is decorated with the TestClass attribute. You also get an automatically created test method decorated with the TestMethod attribute. Both are required to trigger the MSTest framework. Some other handy attributes you can use will help you set up and tear down your tests. These are the TestInitialize and TestCleanup attributes respectively. Methods decorated with the TestInitialize attribute run before any tests are executed, whereas methods decorated with the TestCleanup attribute run after all tests are executed.
Initialize Selenium Webdriver with your app URL in your TestInitialize method, and dispose of it in your TestCleanup method, as shown below. You’ll need a class level variable of type IWebDriver named driver. Super important: when running these UI tests in Azure DevOps you have to init the driver with Environment.GetEnvironmentVariable(“ChromeWebDriver”) so the hosted agent can load it.
The Login method instructs the web driver how to log into my web app. I simply reference the html elements by id and tell it what values to enter.
After your init method, all the test methods labeled with the TestMethod attribute will be run and tracked individually in Azure DevOps. My test method simply shows how to navigate to a URL and take a snapshot. This one of the coolest features. I can look back in my test history to see when a page broke. The snapshots are saved to the cloud under each test result.
I recommend running the tests locally first (remove the environment variable parameter passed to the Chrome Driver constructor). Which brings us to our next part.
Run Your Tests in the Cloud
To get started, you’ll need a build pipeline or a build and deployment pipeline, depending on how you want to configure things. Most times I just have a build pipeline that also releases to at least staging. Creating one is beyond the scope of this article. Add a test assemblies step to your pipeline after whatever step deploys your site. Its under the tests tab in the add step pane.
When added, the step looks like this.
The great thing about it is that the step is configured correctly with the defaults. Make sure the upload test attachments option is checked, and that the select tests using step has test assemblies selected.
View Your Results
Run your pipeline. Your tests will run. The hosted Crome webdrdiver will go out and test your URL (if its publicly accessible). There are two places to view your test results. The first place is the test summary result, under the main left hand side menu : Pipelines > Builds > click a build result > click the tests tab. You’ll get a summary view like below.
The next is under the left hand side menu > Test Plans > the sub menu Test Runs > click a test run. You’ll get a run summary and a test results tab. Under the test results tab is where you can view your screenshots. Under the test results tab, you’ll have to double click a test result to view the details.
Hopefully now you’re off and running building your own UI tests. Enjoy!