stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

wip(tools): xunit runner helper + QA guidance iteration

Browse Source 
Follow-up to SPRINT_20260419_028 TEST-RUNNER-001.

- scripts/test-targeted-xunit.ps1: refinements to the helper.
- docs/code-of-conduct/TESTING_PRACTICES.md: default targeted xUnit v3
  verification to the new helper.
- docs/qa/feature-checks/FLOW.md: call out Microsoft Testing Platform
  filter-ignore behaviour and point to the helper.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
master
2026-04-19 14:48:48 +03:00
parent 333d894690
commit 3d14332609
3 changed files with 22 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/qa/feature-checks/FLOW.md
View File

@@ -176,7 +176,9 @@ the described behavior.
**Process**:
1. Identify the `.csproj` file(s) for the feature's module
2. Run `dotnet build <project>.csproj` and capture output
3. Run `dotnet test <test-project>.csproj --filter <relevant-filter>` -- tests MUST actually execute and pass
3. Run the targeted tests and confirm the filter actually executes the intended subset.
- For VSTest-style projects where filtering works normally, use `dotnet test <test-project>.csproj --filter <relevant-filter>`.
- For xUnit v3 projects running under Microsoft Testing Platform, do **not** rely on `dotnet test --filter`; use `scripts/test-targeted-xunit.ps1` or direct `dotnet exec <test-dll> -method/-class/...` instead.
4. For Angular/frontend features: run `npx ng build` and `npx ng test` for the relevant library/app
5. **Code review** (CRITICAL): Read the key source files and verify:
- The classes/methods described in the feature file actually contain the logic claimed
@@ -364,13 +366,17 @@ integration tests** or **behavioral unit tests** that prove the feature logic:
**Process**:
1. Identify tests that specifically exercise the feature's behavior
2. Run those tests: `dotnet test --filter "FullyQualifiedName~FeatureClassName"`
2. Run those tests using a targeting path that actually filters the assembly:
- VSTest-compatible path: `dotnet test <test-project>.csproj --filter "FullyQualifiedName~FeatureClassName"`
- xUnit v3 / Microsoft Testing Platform path: `pwsh ./scripts/test-targeted-xunit.ps1 -Project <test-project>.csproj -Class "<fully.qualified.class>"`
3. Read the test code to confirm it asserts meaningful behavior (not just "compiles")
4. If no behavioral tests exist, write a focused test and run it
**Example for `evidence-weighted-score-model`**:
```bash
dotnet test --filter "FullyQualifiedName~EwsCalculatorTests"
pwsh ./scripts/test-targeted-xunit.ps1 \
-Project src/Policy/__Tests/StellaOps.Policy.Engine.Tests/StellaOps.Policy.Engine.Tests.csproj \
-Class "StellaOps.Policy.Engine.Tests.Scoring.EwsCalculatorTests"
# Verify: normalizers produce expected dimension scores
# Verify: guardrails cap/floor scores correctly
# Verify: composite score is deterministic for same inputs
@@ -381,7 +387,7 @@ dotnet test --filter "FullyQualifiedName~EwsCalculatorTests"
{
"type": "integration",
"capturedAtUtc": "2026-02-10T12:00:00Z",
"testFilter": "FullyQualifiedName~EwsCalculatorTests",
"testFilter": "StellaOps.Policy.Engine.Tests.Scoring.EwsCalculatorTests",
"testsRun": 21,
"testsPassed": 21,
"testsFailed": 0,