fix(html-report): extract categories using MTP Key=name convention#5946
Conversation
…convention
`HtmlReporter.ExtractTestResult` was checking `IsNullOrEmpty(meta.Key)` to
distinguish categories from key/value custom properties, but Microsoft's
own VSTestBridge convention (and TUnit's own `TestExtensions`) emits
categories as `TestMetadataProperty(name, "")` — name in Key, Value empty.
The check was inverted, so every `[Category]` silently landed in
`customProperties` as `{key:"Async", value:""}` instead of populating the
`categories` array. As a result the HTML report's category-pill UI
(`buildCatPills()` / `#categoryPills`) had nothing to render and stayed
hidden, even for projects that tag every test class.
Switch the field check: `IsNullOrEmpty(meta.Value)` → category (name in
Key), otherwise → custom property. Matches the MTP/VSTestBridge convention
already used elsewhere in TUnit (`TestFilterService.cs:248`,
`TestExtensions.cs:71`) and lets the existing pill UI shipped in #5486
finally light up.
Adds a unit test pinning the split between the two TestMetadataProperty
shapes so the extraction can't silently regress again.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
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.
1 participant
Summary
Fixes a latent bug in the HTML report where
[Category]attributes never made it into the report'scategoriesarray — leaving the category-pill filter UI shipped in #5486 permanently dark.Root cause
Two coordinated emissions, one inverted check:
TestExtensions.cs:71new TestMetadataProperty(category)— single-arg ctorKey=""Async"",Value=""""HtmlReporter.cs:521if (IsNullOrEmpty(meta.Key)) … categories.Add(meta.Value)else, category lands incustomPropertiesMTP's single-arg
TestMetadataProperty(string)constructor stores the argument inKeyand defaultsValueto""""(verified via reflection onMicrosoft.Testing.Platform.dll2.2.3). Microsoft's ownMicrosoft.Testing.Extensions.VSTestBridgeuses 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:
After:
buildCatPills()(HtmlReportGenerator.cs:1353) only renders whencatNames.length > 0, so with no categories ever populated the#categoryPillsrow stayeddisplay: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.TestFilterServiceis unaffected — it builds its ownPropertyBagfromTestDetails.Categoriesdirectly, 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
ExtractTestResult_SortsTestMetadataProperty_Into_Categories_And_CustomPropertiespins the split between the twoTestMetadataPropertyshapes.HtmlReporterTestspass locally (dotnet test --treenode-filter ""/*/*/HtmlReporterTests/*"").TUnit.TestProjectfiltered toCategoryTests(which uses[Category(""ClassCategory"")] [Category(""MethodCategory"")]etc.) and confirmed the decoded report JSON now contains""categories"":[""ClassCategory2"",""ClassCategory"",""MethodCategory2"",""MethodCategory""].[Category].Refs #5912 — discovered while investigating why categories weren't filterable from the HTML report despite being well-supported in the code.