Skip to main content

standalone-test-repro-method

Resolve a CoreCLR runtime test from a fully qualified method name for the standalone-test-repro workflow. Use for xUnit display names and methods in merged or multi-test assemblies, with or without a named test scenario. Continue with the parent standalone-test-repro skill after resolution.

Datos de origen

Repositorio
dotnet/runtime
Última actividad en el origen
19 de agosto de 2026 a las 21:04
Idioma detectado de SKILL.md
inglés
Estrellas
18.335
Forks
5650

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
standalone-test-repro-method
description
Resolve a CoreCLR runtime test from a fully qualified method name for the standalone-test-repro workflow. Use for xUnit display names and methods in merged or multi-test assemblies, with or without a named test scenario. Continue with the parent standalone-test-repro skill after resolution.
# Resolve a Runtime Test Method This is the method-name resolution sub-skill for [`../standalone-test-repro/SKILL.md`](../standalone-test-repro/SKILL.md). Resolve the exact source test, owning project, and test invocation, then continue with the parent's shared extraction steps. ## Input Accept a fully qualified method name copied from a CI failure, for example: ```text Namespace.TypeName.MethodName ``` It may include an assembly prefix, xUnit display-name arguments, quotes, parentheses, nested-type notation, or surrounding CI log text. The surrounding request may also name a scenario such as `jitstress1`; preserve it separately from the method identifier for the parent workflow. ## Resolution 1. Normalize the identifier: - Trim quotes, Markdown formatting, leading result labels, and trailing punctuation. - Preserve xUnit argument text for theory-case resolution. - Remove an assembly prefix only after verifying it is an assembly name. - Never reduce the identifier to only the final method segment. - Do not treat a separately supplied scenario as part of the method name. 2. Parse the longest plausible namespace/type prefix and method name. Account for nested types (`+` in reflection names and `.` in C# source) and generic arity suffixes. 3. Search C# sources under `src/tests/` for the exact method declaration and confirm its containing type and namespace. Prefer symbol information when available; otherwise combine targeted searches for method, type, and namespace. 4. Find the owning `.csproj` by its explicit or evaluated `Compile` items. Account for wildcard includes and merged projects such as JIT regression assemblies. 5. Inspect the project and source for: - `[Fact]`, `[Theory]`, custom attributes, or `TestEntryPoint` - Static or instance invocation and constructor requirements - Fixtures, setup, cleanup, and disposal - Async and generic return or argument handling - Conditional compilation and platform guards - Test data and the specific failing theory row - Target-specific environment items and batch or Bash pre/post commands 6. If display-name arguments identify a theory row, reproduce exactly that row. If not, generate invocations for all locally resolvable rows and label them. Use the `ask_user` tool when runtime-discovered data or ambiguity prevents a faithful choice. 7. If multiple source methods still match, present the concrete candidates with `ask_user`; do not guess. Resolution is complete only when the exact source method, owning project, and required invocation semantics are known. Return any requested scenario unchanged for canonicalization by the `test-scenario-env` skill.
Ver en GitHub