[test-improver] test: add edge case tests for TestContextPropertyUsageAnalyzer (MSTEST0048)#9481
Draft
Evangelink wants to merge 1 commit into
Draft
Conversation
…T0048)
Add 2 new tests targeting untested guard paths in the analyzer:
1. WhenNonTestContextTypeWithSamePropertyNamesAccessedInFixtureMethods_NoDiagnostic
- A custom class with properties named TestData, TestName, TestDisplayName,
FullyQualifiedTestClassName should NOT trigger the diagnostic.
- Directly tests the SymbolEqualityComparer.Default.Equals guard that checks
the property's containing type is actually TestContext.
2. WhenRestrictedTestContextPropertyAccessedInLambdaInsideAssemblyInitialize_Diagnostic
- Accessing TestName/TestData inside a lambda within [AssemblyInitialize] DOES
fire the diagnostic because context.ContainingSymbol for operations inside a
lambda refers to the enclosing named method (not the lambda's anonymous method).
- Confirms the analyzer correctly flags lambda-captured TestContext accesses.
10/10 tests pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds two new unit tests to improve coverage for TestContextPropertyUsageAnalyzer (MSTEST0048), targeting previously untested guard paths around symbol/type filtering and lambda containment.
Changes:
- Added a test ensuring non-
TestContexttypes with restricted property names do not produce diagnostics in fixture methods. - Added a test intended to validate diagnostics when restricted
TestContextproperties are accessed inside a lambda within[AssemblyInitialize].
Show a summary per file
| File | Description |
|---|---|
| test/UnitTests/MSTest.Analyzers.UnitTests/TestContextPropertyUsageAnalyzerTests.cs | Adds two edge-case analyzer tests for non-TestContext property-name collisions and lambda containment scenarios. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Low
Comment on lines
+292
to
+296
| // The analyzer uses context.ContainingSymbol, which for operations inside a lambda refers | ||
| // to the enclosing named method (not the lambda's anonymous method). Therefore the | ||
| // [AssemblyInitialize] attribute is still visible and the diagnostic fires correctly — | ||
| // the lambda will be invoked during assembly initialization where these properties are unavailable. | ||
| string code = """ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Goal and Rationale
TestContextPropertyUsageAnalyzer(MSTEST0048) had 10 tests but two distinct guard paths in itsAnalyzePropertyReferencemethod were completely untested:TestContexttype with restricted property namesSymbolEqualityComparer.Default.Equals(propertyReference.Property.ContainingType, testContextSymbol)context.ContainingSymboltracing through lambdasContainingSymbolresolves inside a lambda bodyApproach
Two focused tests were added:
WhenNonTestContextTypeWithSamePropertyNamesAccessedInFixtureMethods_NoDiagnosticCreates a
FakeContextclass with properties namedTestData,TestName,TestDisplayName, andFullyQualifiedTestClassName— same names as restrictedTestContextproperties — then accesses them inside[AssemblyInitialize]and[ClassInitialize]. No diagnostic expected; confirms theSymbolEqualityComparerguard correctly filters out non-TestContextproperty references.WhenRestrictedTestContextPropertyAccessedInLambdaInsideAssemblyInitialize_DiagnosticAccesses
testContext.TestNameandtestContext.TestDatainside a lambda defined within[AssemblyInitialize]. The test confirms the analyzer fires diagnostics here becausecontext.ContainingSymbolfor operations inside a lambda resolves to the enclosing named method (not the lambda's anonymous function), so the[AssemblyInitialize]attribute is still visible. This is correct behavior: the lambda will be invoked during assembly initialization, where these properties are unavailable.Coverage Impact
TestContextPropertyUsageAnalyzerTestsTest Status
All 12/12 tests pass (
net8.0,Debug):Reproducibility
Add this agentic workflows to your repo
To install this agentic workflow, run