How to Set Up Selenium WebDriver for MSTest
Create an MSTest project, add Selenium WebDriver, and run a local browser test. Compare MSTest.Sdk with manual package setup and learn how to troubleshoot common issues.
To run Selenium WebDriver tests with MSTest, create a .NET test project, add Selenium.WebDriver from NuGet, and create a ChromeDriver inside an MSTest test method. For a new project that can use the standard .NET SDK base, Microsoft recommends MSTest.Sdk. If your project needs another base SDK, configure the MSTest packages manually. Selenium Manager handles driver setup in the documented quick start, so you usually do not need to download ChromeDriver separately for a local test.
1. Choose an MSTest project setup
There are two common ways to configure MSTest. Pick the one that fits the project’s SDK and test runner before adding Selenium.
| Approach | Use it when | What to check |
|---|---|---|
MSTest.Sdk |
You are starting a project that can use Microsoft.NET.Sdk as its base. |
It provides first-party MSTest runner and Microsoft.Testing.Platform defaults. Check Microsoft’s current guidance for any runner-specific settings. |
| Manual package references | The project must use a different base SDK, such as Microsoft.NET.Sdk.Web, or your repository already follows the VSTest package path. |
Keep the test SDK, MSTest framework and adapter, and Selenium package versions compatible with the target framework and runner. |
Microsoft describes MSTest.Sdk as a meta-package that brings together the framework, adapter, analyzers, and supporting test packages. Manual references remain useful when the project cannot change its base SDK. Follow the runner path already used by your repository rather than mixing configuration styles casually. See Microsoft’s MSTest.Sdk documentation and MSTest test documentation.
2. Create the test project
Option A: Start with MSTest.Sdk
Use the installed .NET SDK to create a test project:
dotnet new mstest -n SeleniumMSTest
cd SeleniumMSTestInspect the generated project file and confirm it uses the MSTest SDK style recommended by your installed templates. Templates and SDK behavior can change; if the generated project uses conventional package references, use the manual setup below instead of assuming a particular template output.
Option B: Configure a conventional project manually
Create a standard project and add MSTest packages. Exact package versions are intentionally not pinned here: choose versions available for your target framework and the runner your repository uses.
dotnet new classlib -n SeleniumMSTest
cd SeleniumMSTest
dotnet add package Microsoft.NET.Test.Sdk
dotnet add package MSTest.TestAdapter
dotnet add package MSTest.TestFrameworkEnsure the project is marked for test execution if required by its SDK and runner. The conventional Selenium project sample references Microsoft.NET.Test.Sdk, MSTest.TestAdapter, and MSTest.TestFramework. Microsoft’s setup guidance explains the runner and package configuration choices.
3. Add Selenium WebDriver
Install Selenium’s .NET WebDriver package in the test project:
dotnet add package Selenium.WebDriverNuGet also supports adding a PackageReference in the project file. If you pin a version, check the Selenium.WebDriver NuGet page when publishing or setting up the repository. The research checked for this article found a version discrepancy: NuGet surfaced 4.50.0, while Selenium’s downloads page and its sample project listed 4.49.0. Those listings can change, so verify the version available for your framework rather than treating either number as permanently current.
The Selenium installation sample uses .NET 8, Selenium WebDriver and Support 4.49.0, MSTest adapter and framework 3.6.0, and Microsoft.NET.Test.Sdk 17.11.1. These are sample pins, not a recommendation that they are the latest versions. If you also add Selenium.Support for helper APIs, keep its version aligned with Selenium.WebDriver; the NuGet metadata requires a compatible WebDriver version. Support is not required for the basic driver creation example.
For a package-file example and installation details, see Selenium’s .NET library installation guide and downloads page.
4. Write and run a minimal browser test
Add a test class such as HomePageTests.cs to the test project. This example launches Chrome, opens a page, checks its title, and disposes the driver even if an assertion fails:
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium.Chrome;
namespace SeleniumMSTest;
[TestClass]
public class HomePageTests
{
[TestMethod]
public void OpensExamplePage()
{
using var driver = new ChromeDriver();
driver.Navigate().GoToUrl("https://example.com");
Assert.AreEqual("Example Domain", driver.Title);
}
}Run it from the project directory:
dotnet testThe Selenium quick start demonstrates the ChromeDriver, navigation, and title-reading pattern. The MSTest attributes and assertion make it an MSTest test. This code assumes Chrome is installed and usable in the execution environment. Selenium Manager handles obtaining the matching driver in the documented quick start; the browser itself still needs to be available.
5. Understand browser and driver setup
- Browser: Install Chrome in the environment where the test runs. A driver cannot launch a browser that is missing or inaccessible.
- Driver: Selenium Manager handles browser-driver setup for the documented quick-start path. A separate manual ChromeDriver download is not normally the first setup step.
- Selenium Server: A local WebDriver script does not need Selenium Server. Server/Grid is for Remote WebDriver and distributed execution.
For CI or remote execution, make the browser installation and environment explicit in the job configuration. Introduce Selenium Grid or another remote WebDriver endpoint only when tests need a browser on a separate machine or distributed capacity. See Selenium’s WebDriver documentation.
6. Configure the test project for your repository
- Target framework: Choose a framework supported by your installed .NET SDK and the package versions you select. The reviewed NuGet listing showed Selenium.WebDriver support for .NET Framework 4.6.2, .NET Standard 2.0, and .NET 8.0; check the live package metadata for current support.
- SDK style: Use
MSTest.Sdkwhen it can be the project’s base SDK. Projects that need a different SDK, such as Web SDK, can use manual MSTest package references. - Runner: Confirm whether the repository uses MSTest runner/Microsoft.Testing.Platform or the VSTest integration path. Configure the project consistently with that choice.
- Package alignment: Restore packages and check that versions support the target framework. If using both Selenium.WebDriver and Selenium.Support, align their versions.
- Local versus remote: Keep the local path simple. Configure Remote WebDriver/Grid only for a remote browser requirement.
7. Troubleshoot common setup failures
| Symptom | Likely cause | What to do |
|---|---|---|
dotnet test reports no tests |
The project is not configured with the expected MSTest framework, adapter, or runner integration. | Check the project SDK and package references. Ensure the repository uses a consistent MSTest runner path and that the test class and method have [TestClass] and [TestMethod]. |
| Package restore fails | A package version is unavailable, incompatible with the target framework, or conflicts with another package. | Check NuGet package metadata and the project’s target framework. Align Selenium.WebDriver and Selenium.Support versions if both are referenced. |
| Chrome does not start | Chrome is missing, inaccessible, or cannot run in the current environment. | Install or enable Chrome in that environment, then rerun the test. Check the process account and environment restrictions. |
| Driver cannot be resolved or launched | Driver setup could not complete, or the environment cannot access the browser or required driver resources. | Check the Selenium Manager output and environment access. Confirm the browser is installed and compatible with the chosen Selenium package. Use manual driver configuration only when the environment requires it. |
| Browser opens locally but fails in CI | The CI image may not include a browser or may run with different permissions and environment settings. | Provision the browser in the CI job, inspect its logs, and configure a remote browser only if execution must occur elsewhere. |
| WebDriver session creation fails against a remote endpoint | The remote server is unavailable or the endpoint/capabilities do not match the remote setup. | Verify the remote WebDriver endpoint and server/Grid configuration. A local ChromeDriver example does not configure a remote session. |
8. Performance, reliability, and cost
A local browser test starts a real browser process, so it has more setup and resource cost than a unit test. Reuse a driver within a test where appropriate, but dispose it reliably with using. Keep tests independent so one failed browser session does not leave later tests sharing unexpected state. For parallel execution, account for the CPU and memory used by each browser process and avoid sharing one driver instance across tests.
For reliability, pin compatible package versions in the project and make the browser available consistently in local and CI environments. A successful NuGet restore alone does not prove the browser can launch. Local execution does not require Selenium Server; remote execution adds the availability and configuration of the remote endpoint.
Costs depend on the machines or CI capacity used to run browsers and on any remote Grid infrastructure you operate. Selenium itself is installed as a .NET package. The cited setup material provides no universal execution cost or benchmark, so estimate from your own environment and workload.
Or skip the browser setup
If your task is to capture a page image rather than interactively test browser behavior, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. It accepts cookie and consent banners like a visitor, removes 60+ known consent platforms, newsletter popups, and chat widgets before capture, and lets you turn each step off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month without a card; paid plans start at $5 for 3,000 shots. Every feature is on every plan.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);See the ScreenshotNeo API documentation for request options. Sign up for 1,000 free screenshots a month with no card.
FAQ
Do I need to install ChromeDriver manually?
Usually not for the documented local quick start: Selenium Manager handles browser-driver setup. Chrome itself must still be installed and usable.
Do I need Selenium Server for MSTest?
No, not for a local WebDriver test. Selenium Server is used for Remote WebDriver/Grid execution.
Is MSTest.Sdk required?
No. It is Microsoft’s recommended first-party setup for many new projects. Manual package configuration is an option when another base SDK or existing runner setup requires it.
Should I add Selenium.Support?
Only when you need its helper APIs. It is not necessary for the basic ChromeDriver example.
Which Selenium .NET version should I install?
Check the current NuGet listing and compatibility for your target framework at setup time. The reviewed NuGet and Selenium downloads listings did not agree on the newest version.
