TestVibe inside Visual Studio

Most of the day, a .NET developer lives in Visual Studio. Test evidence usually lives somewhere else — a separate tab, a separate tool, a context switch every time you want to know whether a change broke a flow. The TestVibe extension for Visual Studio 2022 closes that gap: it brings your TestVibe project into the IDE as a set of tool windows, so you can see coverage, browse features and runs, and act on gaps without leaving the editor.

What the extension is

It is a thin client, not a second product. Every action it takes goes through the same TestVibe REST API that the testvibe CLI and MCP server use — there is no separate logic, no local test engine, and nothing to keep in sync by hand. When a feature is generated or a run completes, the source of truth is still your TestVibe project; the extension just reads and writes that same state from a window that happens to live where you already work.

Connect it once

The extension authenticates with a TestVibe API key — the same tvb_… keys you create under Settings → CLI & API keys in the web app. Create one key per machine so revocation stays painless, then paste it into the extension's options page. Keys are stored encrypted at rest for the current Windows user, so they are not sitting in plaintext next to your solution.

Binding a solution to a project reuses the same connection the CLI sets up. If you have already signed in and picked a project with the CLI in this repo, the extension picks up that binding automatically:

testvibe login --server https://your-testvibe-url --key tvb_...
testvibe use checkout-web

Otherwise, use TestVibe → Bind project… to pick from your projects directly in the IDE.

Coverage, next to the code it measures

The strongest reason to have TestVibe in the IDE is coverage. TestVibe's App Code view maps your connected source repository against the UI tests that exercise it, so untested code surfaces first. The extension brings that same map inside Visual Studio.

A dedicated Coverage tool window shows the project's coverage headline and a gaps-first file tree: folders and files ordered so the parts nothing tests float to the top. Expand a file and you get its Tested by panel — the features that map to it, each with its last pass or fail status. The same search and gaps-first filters from the web app's App Code view carry over.

Coverage also reaches the editor itself through a margin strip that marks a file's status — executed, tested, untested, or unknown — with a tooltip explaining what you are looking at. It is a quiet signal in the gutter, not an overlay fighting for attention, and it answers the question you actually have while reading a file: is this covered by anything?

If a mapping is wrong, you can steer it. A @covers: tag on a Gherkin scenario links that scenario straight to a source file, and your corrections survive re-scans:

@covers:Services/CheckoutService
Scenario: Applying a valid discount code reduces the total
  Given a cart with one item at 40.00
  When the shopper applies code SAVE10
  Then the order total shows 36.00

Add a path qualifier like that when a bare class name matches more than one file — otherwise the tag is left unmapped rather than guessed.

Act on a gap without leaving the file

Because the extension talks to the ops API, it can do more than display. From Solution Explorer you can act on the file in front of you — generate a feature that covers it, or run the tests that already cover it — and the request is handed to TestVibe's cloud, the same fleet that runs every other TestVibe test. Alongside Coverage, tool windows for Runs, Features, and Automations let you browse the rest of your project's state in the IDE instead of alt-tabbing to a browser.

You still review the generated Playwright in your project and read full run evidence — screenshots, video, traces — in the web app, where that surface is richest. The extension's job is to remove the trip: notice a gap while reading code, do something about it, and keep going.

Who it is for

This is aimed squarely at developers on .NET teams who want quality signals where they already are. If you are the person reviewing generated tests, closing coverage gaps before a merge, and diagnosing failures, an in-IDE view of what is and is not tested is worth more than the same information one tab away. QA and product still work in the web app; the extension is the developer's on-ramp to the same project.

Building this workflow needs Visual Studio 2022 and a TestVibe project with a connected source repository. Want to try TestVibe? Get early access, or read more about coverage in the App Code docs.