Precept Test Explorer

A VS Code extension for Precept test automation projects (.NET, built on Microsoft.Testing.Platform). It lives in its own Activity Bar view, separate from the built-in Testing view.

Features

• Project discovery — every .csproj in the workspace is inspected, and a project is listed when it is a Precept test project: it references Precept.TestPlatform (as a PackageReference/ProjectReference, directly or via a Directory.Build.props) or sets IsTestingPlatformApplication to true. A precept.json is not required — a suite that runs on Precept's defaults is discovered like any other. Libraries that set IsTestingPlatformApplication to false and dotnet new template sources (a .template.config directory) are skipped; that is also why a precept.json alone never qualifies a project, since the file ships as template content inside the package and the templates. The "Precept" output channel logs any project that carries a precept.json but was skipped, and why.
• Test discovery — scans .cs files (including Reqnroll-generated *.feature.cs) for [TestSuite]/[Test]/[TestCase] attributes and builds a tree grouped by project → class → test, without requiring a build.
• Configuration view — reads precept.json and precept.{environment}.json, shows the effective merged configuration per project, and lets you switch the active environment. A project without a precept.json shows as running on Precept's defaults; editing a value there creates the file.
• Config overrides — edit values from the tree (written into the active environment's overlay file, so changes can be committed), or supply ad-hoc PRECEPT_* environment variable overrides for a single run without touching any file.
• Local environment variables per configuration — each configuration (precept.dev.json, precept.staging.json, or the base precept.json alone) has its own set of extra environment variables under Local environment variables in the Configuration view. They are passed to every run and debug session while that configuration is selected, so they behave like PRECEPT_* overrides, but they are never written to any precept*.json: values live in VS Code's secret storage (the OS keychain) on this machine only. That makes them the place for API keys, passwords and tokens that a committed config file must not contain. Values are masked in the tree; use the eye icon to reveal one. A one-off override from Run Test with Config Overrides... still wins over a stored value of the same name.
• Config-driven filtering — a project's effective Filter.Include/Filter.Exclude (base config merged with the active environment's overlay) is applied to both test explorers, so a test the config excludes for this environment is genuinely absent from the list rather than just failing when run.
• Category filtering — filter the visible test tree by [TestCategory] tags.
• Run & debug — run a project, class, test, or individual data row via dotnet run (which builds the project first, so runs always reflect the latest code), with results (pass/fail/skip, duration, error output) parsed from the TRX report and shown as icons in the tree. Debugging runs an explicit dotnet build and then launches the built assembly under the C# extension's debugger.
• Report — a dedicated Report view showing the last run's TRX report per project, grouped by class and test, with links to any files a test attached via TestContext.AddResultFile (screenshots, logs, traces). Only appears once a run has produced a TRX report. Reports are written next to the test project, under TestResults/vscode (TestResults/vscode-debug for debug sessions), so the run.trx and its attachments stay browsable outside VS Code; each run clears its own directory first. Add TestResults/ to .gitignore if your repo doesn't already ignore it.

Requirements

• The .NET SDK, with a global.json (at or above the project) containing:

  { "test": { "runner": "Microsoft.Testing.Platform" } }
  

• The C# extension for the "Debug Test" action.

Settings

Duplicate tests in the Testing view

C# Dev Kit discovers Precept projects too — they are Microsoft.Testing.Platform applications — and VS Code lists every extension's tests side by side without de-duplicating them, so both copies show up under the built-in Testing view. With the default precept.testingViewIntegration: "auto", Precept detects C# Dev Kit and stays out of that view: Dev Kit owns the Testing view, and the Precept sidebar remains the place for environment selection, config overrides, category filters, and reports. Set it to "always" if you would rather have both listings (or if you have disabled Dev Kit's test discovery), or to "never" to keep Precept out of the Testing view regardless. Note that with the mirror off, runs started from the Precept sidebar no longer paint the editor's gutter pass/fail decorations, since those come from the Testing API.

If runs fail with a CLI/argument error that works fine in a terminal: VS Code launched from Finder/Dock (rather than a terminal) can see a different PATH than your shell, so the unqualified dotnet may resolve to an unrelated or older SDK. The "Precept" output channel logs which dotnet executable was actually resolved before every run — compare it against which dotnet in your terminal, and set precept.dotnetPath to the absolute path if they differ.

Known limitations (v1)

• Discovery is a heuristic source scanner, not a full C# parser — it assumes conventional formatting and may miss unusual layouts. String literals (regular, verbatim, interpolated and raw) and comments are skipped, so source written inside a string never registers as a suite; the one shape it still reads wrong is a string nested in an interpolation hole ($"{"x"}").
• Running/debugging a single row of a [TestCase]-parameterized test before it has ever run falls back to a name-prefix filter over the method, since Precept doesn't expose the per-row identity until a run has produced a TRX report.
• Gherkin .feature.cs files must exist on disk (i.e., the project must have been built at least once by Reqnroll's generator) to be discovered. A code-behind whose .feature file has since been deleted is skipped, since Reqnroll leaves it out of the build; the "Precept" output channel names each one, and a Clean or Rebuild removes the file.
• Test projects without the optional Microsoft.Testing.Extensions.TrxReport package are run again without TRX reporting, and results are read from the run's console output instead. That path matches results to tests by display name, so it can't distinguish two identically named tests in different classes, and it carries less failure detail than a TRX report. Runs are pinned to English (DOTNET_CLI_UI_LANGUAGE=en) so those console outcomes stay readable on a localized SDK; set the variable yourself in a run's environment variables if you'd rather keep your own language and have the package installed.

Development

npm install
npm run watch    # or press F5 to launch an Extension Development Host

npm run compile / npm run package bundle with esbuild; npm run lint and npm run check-types validate the source.