
Browser automation and testing for .NET that talks straight to the browser over CDP and WebDriver BiDi. No Node.js sidecar, no driver binaries, and every built-in feature is a plugin you could have written yourself.
Browser testing from .NET has meant borrowing someone else's runtime. One popular framework proxies every command through a Node.js process; another routes them through a driver binary per browser. Either way there is a process boundary between your test and the page, a second toolchain to install in CI, and an extension model that was never designed for you.
Motus removes the boundary. Your test process opens a WebSocket to the browser and speaks its native protocol.
A browser automation library, an assertion library with auto-waiting, adapters for MSTest, xUnit, and NUnit, a command-line tool, and an MCP server so an AI agent can drive the same browser your tests do. Source-generated protocol bindings keep it NativeAOT friendly, and Roslyn analyzers flag common automation mistakes at compile time.
using Motus;
using Motus.Testing.MSTest;
using static Motus.Assertions.Expect;
[MotusTestClass]
public class SearchTests : MotusTestBase
{
[TestMethod]
public async Task SearchReturnsResults()
{
var page = await Context.NewPageAsync();
await page.GotoAsync("https://example.com");
await page.Locator("input[name='q']").FillAsync("motus automation");
await page.Locator("button[type='submit']").ClickAsync();
await That(page).ToHaveUrlAsync("**/search**");
await That(page.Locator(".results")).ToBeVisibleAsync();
}
}
Every built-in selector strategy, lifecycle hook, wait condition, and reporter is registered through the same plugin context a third party uses. There are no internal shortcuts, which is the only way to know the extension surface is good enough.
If the framework's own features are built on the public plugin interfaces, the architecture stays honest.
Where Motus sits next to the frameworks .NET teams already use.
| Motus | Playwright for .NET | Selenium | |
|---|---|---|---|
| Transport | CDP and WebDriver BiDi over WebSocket, from your process | A Node.js driver process that the .NET package launches and talks to | The WebDriver protocol through a driver binary per browser |
| Browsers | Chrome, Edge, Firefox | Chromium, Firefox, WebKit | Chrome, Edge, Firefox, Safari, and others |
| Extensibility | Every built-in is a plugin on public interfaces | Fixtures and configuration | Listeners and WebDriver extension points |
| For agents | MCP server in the box | A separate MCP server project | Third party |
| Test frameworks | MSTest, xUnit, NUnit adapters | MSTest, xUnit, NUnit adapters | Any |
| License | MIT | Apache 2.0 | Apache 2.0 |
The Datafication SDK loads and shapes the data, Verso is where you explore it, and Motus proves what you shipped in a real browser. We use it to test Verso's own browser host.
dotnet add package Motusdotnet add package Motus.Testing.MSTest (or xUnit, NUnit)dotnet tool install --global Motus.Cli