fix(html-report): extract categories using MTP Key=name convention

[thomhurst]

Summary

Fixes a latent bug in the HTML report where [Category] attributes never made it into the report's categories array — leaving the category-pill filter UI shipped in #5486 permanently dark.

Root cause

Two coordinated emissions, one inverted check:

File	Emits	Result
TestExtensions.cs:71	new TestMetadataProperty(category) — single-arg ctor	Key=""Async"", Value=""""
HtmlReporter.cs:521	if (IsNullOrEmpty(meta.Key)) … categories.Add(meta.Value)	branches to else, category lands in customProperties

MTP's single-arg TestMetadataProperty(string) constructor stores the argument in Key and defaults Value to """" (verified via reflection on Microsoft.Testing.Platform.dll 2.2.3). Microsoft's own Microsoft.Testing.Extensions.VSTestBridge uses the same shape — new TestMetadataProperty(category, string.Empty) (ObjectModelConverters.cs lines 72-76). So the emitter is right; the extractor's field check is inverted.

Before the fix, decoding the embedded gzipped data blob from a report shows:

""customProperties"":[{""key"":""Async"",""value"":""""},{""key"":""DataSource"",""value"":""""}]

After:

""categories"":[""Async"",""DataSource""]

buildCatPills() (HtmlReportGenerator.cs:1353) only renders when catNames.length > 0, so with no categories ever populated the #categoryPills row stayed display:none.

Fix

Swap the field check — IsNullOrEmpty(meta.Value) distinguishes the category shape (name in Key, empty Value) from the trait/property shape (non-empty Value). One-file change.

TestFilterService is unaffected — it builds its own PropertyBag from TestDetails.Categories directly, which is why CLI --treenode-filter ""/*/*/*/*[Category=X]"" always worked.

Side-effect: [Property(""X"", """")]

A user-defined [Property(""X"", """")] (empty value) will now classify as a category named ""X"" rather than a custom property with empty value. This is consistent with the convention (empty value = tag) and matches Microsoft's bridge behaviour.

Test plan

• New unit test ExtractTestResult_SortsTestMetadataProperty_Into_Categories_And_CustomProperties pins the split between the two TestMetadataProperty shapes.
• All 14 HtmlReporterTests pass locally (dotnet test --treenode-filter ""/*/*/HtmlReporterTests/*"").
• Verified end-to-end: ran TUnit.TestProject filtered to CategoryTests (which uses [Category(""ClassCategory"")] [Category(""MethodCategory"")] etc.) and confirmed the decoded report JSON now contains ""categories"":[""ClassCategory2"",""ClassCategory"",""MethodCategory2"",""MethodCategory""].
• (Reviewer) Spot-check a real report in a browser: category pills should appear under the toolbar for any test class with [Category].

Refs #5912 — discovered while investigating why categories weren't filterable from the HTML report despite being well-supported in the code.

[claude]

Code Review

Overall: Clean, well-motivated fix. Approve.

The Fix (HtmlReporter.cs:521)

The inverted field check is the correct diagnosis. MTP's single-arg ctor stores the value in with defaulting to , so the previous branch was never entered for real categories — they silently fell through to customProperties. The swap to IsNullOrEmpty(meta.Value) matches the actual MTP/VSTestBridge convention and is well-evidenced by the referenced source.

Visibility change (private → internal static)

Safe — TUnit.Engine.Tests is already in InternalsVisibleTo in the csproj, so this doesn't expand the public surface area.

Test coverage

The new test ExtractTestResult_SortsTestMetadataProperty_Into_Categories_And_CustomProperties directly exercises all three cases (two categories + one trait) and pins the split. The comment explaining the MTP convention is justified given how non-obvious the ctor behavior is.

Minor: edge case worth noting

A TestMetadataProperty("", "") (both empty) would now add an empty string to categories. This was already broken before (it would have added empty string to custom properties), so it's not a regression — but it might be worth a guard like !string.IsNullOrEmpty(meta.Key) in the category branch if defensive hygiene is desired. Not a blocker.

Side-effect documented in PR

The behavior change for [Property("X", "")] (reclassified from custom property to category) is intentional and consistent with the convention. The PR description calls this out clearly — no action needed.

The fix is minimal, targeted, and well-tested. Ship it.

[claude]

Code Review

Overall: Clean, well-motivated fix. Approve.

The Fix (HtmlReporter.cs:521)

The inverted field check is the correct diagnosis. MTP's single-arg TestMetadataProperty(string) ctor stores the value in Key with Value defaulting to "", so the previous IsNullOrEmpty(meta.Key) branch was never entered for real categories — they silently fell through to customProperties. The swap to IsNullOrEmpty(meta.Value) matches the actual MTP/VSTestBridge convention and is well-evidenced by the referenced source.

Visibility change (private → internal static)

Safe — TUnit.Engine.Tests is already in InternalsVisibleTo in the csproj, so this doesn't expand the public surface area.

Test coverage

The new test ExtractTestResult_SortsTestMetadataProperty_Into_Categories_And_CustomProperties directly exercises all three cases (two categories + one trait) and pins the split. The comment explaining the MTP convention is justified given how non-obvious the ctor behavior is.

Minor: edge case worth noting

A TestMetadataProperty("", "") (both empty) would now add an empty string to categories. This was already broken before (it would have added empty string to custom properties instead), so it's not a regression — but a guard like !string.IsNullOrEmpty(meta.Key) inside the category branch would be a cheap defensive improvement. Not a blocker.

Side-effect documented in PR

The behavior change for [Property("X", "")] (reclassified from custom property to category) is intentional and consistent with the convention. The PR description calls this out clearly — no action needed.

The fix is minimal, targeted, and well-tested. Ship it.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}