Run any Skill in Manus with one click

platform-detection

Stars3,575

Forks266

UpdatedJune 23, 2026 at 09:03

Reference data for detecting the test platform (VSTest vs Microsoft.Testing.Platform) and test framework (MSTest, xUnit, NUnit, TUnit) from project files. DO NOT USE directly — loaded by run-tests, mtp-hot-reload, and migrate-vstest-to-mtp when they need detection logic.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

dotnet

dotnet/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

More from this repository

same repository

dotnet-pinvoke

dotnet/skills

Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.

2026-06-293.6k

extension-points

dotnet/skills

Guide for MSBuild extensibility: CustomBefore/CustomAfter hooks, wildcard imports with alphabetic ordering, import gating with control properties, NuGet package build extension layout (build/buildTransitive), and the MicrosoftCommonPropsHasBeenImported guard. USE FOR: diagnosing and fixing MSBuild import and hook patterns, reviewing and fixing extension point anti-patterns in Directory.Build files, fixing missing Exists() guards on imports that break fresh clones, fixing NuGet package hooks being silently dropped instead of appended, making build targets extensible for other projects, injecting custom logic into the build pipeline, creating NuGet packages that extend the build, conditionally disabling imports. DO NOT USE FOR: target authoring patterns (use target-authoring), props vs targets placement (use directory-build-organization), general anti-patterns (use msbuild-antipatterns), non-MSBuild build systems.

2026-06-293.6k

msbuild-antipatterns

dotnet/skills

Catalog of MSBuild anti-patterns with detection rules and fix recipes. USE FOR: reviewing, auditing, or cleaning up .csproj, .vbproj, .fsproj, .props, .targets, or .proj files. Each anti-pattern has a symptom, explanation, and concrete BAD→GOOD transformation. Covers Exec-instead-of-built-in-task, unquoted conditions, hardcoded paths, restating SDK defaults, scattered package versions, and more. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake, etc.), project migration to SDK-style (use msbuild-modernization).

2026-06-293.6k

assertion-quality

dotnet/skills

Analyzes the variety and depth of assertions across test suites in any language. Use when the user asks to evaluate assertion quality, find shallow tests, identify assertion-free tests (no assertions or only trivial ones like Assert.IsNotNull / toBeTruthy()), flag self-referential or tautological assertions, measure assertion diversity, or audit whether tests verify different facets of behavior. Polyglot: .NET, Python, TS/JS, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, C++. DO NOT USE FOR: writing new tests (use code-testing-agent / writing-mstest-tests), mutation reasoning about whether tests would catch a bug (use test-gap-analysis), or a general severity-ranked anti-pattern audit (use test-anti-patterns), fixing or rewriting assertions, or writing, fixing, or modernizing MSTest tests, assertions, or attributes (use writing-mstest-tests).

2026-06-263.6k

test-anti-patterns

dotnet/skills

Audits an existing test file or suite in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical/Warning/Info). INVOKE whenever asked to audit or review tests, find what's wrong with a suite, judge whether tests are any good, or check for: tests that pass but verify nothing, missing assertions, swallowed exceptions, self-comparing / tautological assertions, coverage-touching tests, broad exceptions, flaky or order-dependent tests (Thread.Sleep, DateTime.Now, shared state), duplicated tests, or magic values — in .NET, Python/pytest, TS/Jest, Java, Go, Ruby or C++. DO NOT USE FOR: writing new tests (use code-testing-agent, or writing-mstest-tests for MSTest); running tests (use run-tests); migration; assertion-diversity metrics (use assertion-quality); coverage/CRAP metrics (use coverage-analysis); the testsmells.org academic catalog (use test-smell-detection); fixing or modernizing MSTest tests, assertions, attributes, or lifecycle (use writing-mstest-tests).

2026-06-263.6k

coverage-analysis

dotnet/skills

Project-wide code coverage and CRAP (Change Risk Anti-Patterns) score analysis for .NET projects. Calculates CRAP scores per method and surfaces risk hotspots — complex code with low coverage that is dangerous to modify. Use to diagnose why coverage is stuck or plateaued, identify what methods block improvement, or get project-wide coverage analysis with risk ranking. USE FOR: coverage stuck, coverage plateau, can't increase coverage, what's blocking coverage, coverage gap, CRAP scores, risk hotspots, where to add tests, coverage analysis, coverage report. DO NOT USE FOR: targeted single-method CRAP analysis (use crap-score); auditing test code for coverage-touching or other anti-patterns (use test-anti-patterns); writing tests; running tests (use run-tests). Requires or produces coverage (Cobertura) and CRAP metrics.

2026-06-253.6k

name	platform-detection
description	Reference data for detecting the test platform (VSTest vs Microsoft.Testing.Platform) and test framework (MSTest, xUnit, NUnit, TUnit) from project files. DO NOT USE directly — loaded by run-tests, mtp-hot-reload, and migrate-vstest-to-mtp when they need detection logic.
user-invocable	false
disable-model-invocation	true
license	MIT

Test Platform and Framework Detection

Determine which test platform (VSTest or Microsoft.Testing.Platform) and which test framework (MSTest, xUnit, NUnit, TUnit) a project uses.

Detection files to always check (in order): global.json → .csproj → Directory.Build.props → Directory.Packages.props

Detecting the test framework

Read the .csproj file and Directory.Build.props / Directory.Packages.props (for centrally managed dependencies) and look for:

Package or SDK reference	Framework
`MSTest` (metapackage, recommended) or `<Sdk Name="MSTest.Sdk">`	MSTest
`MSTest.TestFramework` + `MSTest.TestAdapter`	MSTest (also valid for v3/v4)
`xunit`, `xunit.v3`, `xunit.v3.mtp-v1`, `xunit.v3.mtp-v2`, `xunit.v3.core.mtp-v1`, `xunit.v3.core.mtp-v2`	xUnit
`NUnit` + `NUnit3TestAdapter`	NUnit
`TUnit`	TUnit (MTP only)

Detecting the test platform

The detection logic depends on the .NET SDK version. Run dotnet --version to determine it.

.NET SDK 10+

On .NET 10+, the global.json test.runner setting is the authoritative source:

If global.json contains "test": { "runner": "Microsoft.Testing.Platform" } → MTP
If global.json has "runner": "VSTest", or no test section exists → VSTest

Important: On .NET 10+, <TestingPlatformDotnetTestSupport> alone does not switch to MTP. The global.json runner setting takes precedence. If the runner is VSTest (or unset), the project uses VSTest regardless of TestingPlatformDotnetTestSupport.

.NET SDK 8 or 9

On older SDKs, check these signals in priority order:

1. Check the <TestingPlatformDotnetTestSupport> MSBuild property. Look in the .csproj, Directory.Build.props, and Directory.Packages.props. If set to true in any of these files, the project uses MTP.

Critical: Always read Directory.Build.props and Directory.Packages.props if they exist. MTP properties are frequently set there instead of in the .csproj, so checking only the project file will miss them.

2. Check project-level signals:

Signal	Platform
`<Sdk Name="MSTest.Sdk">` as project SDK	MTP by default
`<UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>`	MTP runner (xUnit)
`<EnableMSTestRunner>true</EnableMSTestRunner>`	MTP runner (MSTest)
`<EnableNUnitRunner>true</EnableNUnitRunner>`	MTP runner (NUnit)
`Microsoft.Testing.Platform` package referenced directly	MTP
`TUnit` package referenced	MTP (TUnit is MTP-only)

Note: The presence of Microsoft.NET.Test.Sdk does not necessarily mean VSTest. Some frameworks (e.g., MSTest) pull it in transitively for compatibility, even when MTP is enabled. Do not use this package as a signal on its own — always check the MTP signals above first. Key distinction: VSTest is the classic platform that uses vstest.console under the hood. Microsoft.Testing.Platform (MTP) is the newer, faster platform. Both can be invoked via dotnet test, but their filter syntax and CLI options differ.