feat: TUnit0064 analyzer + code fix for direct WebApplicationFactory inheritance

[thomhurst]

Summary

• New analyzer TUnit0064 (Warning) — flags classes directly inheriting Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory<T> instead of TUnit.AspNetCore.TestWebApplicationFactory<T>.
• New code fix — rewrites the base type to TestWebApplicationFactory<T> and adds using TUnit.AspNetCore;.
• New TUnit.AspNetCore.Analyzers.CodeFixers project, bundled into the TUnit.AspNetCore nupkg.
• Docs updated in examples/aspnet.md and guides/distributed-tracing.md.

Closes #5596.

Details

Direct inheritance silently loses:

• Distributed tracing — server-side spans no longer link back to the triggering test.
• Per-test logging — ILogger output from inside the app isn't routed to the right test output.
• Test context — TestContext.Current won't resolve inside request handlers.

The analyzer reports on the base type location (not the class identifier) so the squiggle sits where the offending inheritance is declared. It ignores TestWebApplicationFactory<T> itself. Transitive cases (class inherits a user type that inherits TestWebApplicationFactory<T>) are implicitly safe: the direct base isn't WebApplicationFactory, so the analyzer exits early.

Test plan

• Analyzer warns on direct inheritance
• No warning when using TestWebApplicationFactory<T>
• No warning on transitive TestWebApplicationFactory<T> inheritance
• Diagnostic reports at base-type location (not class identifier)
• Code fix rewrites base type and adds using TUnit.AspNetCore;
• Verified codefix DLL is bundled at analyzers/dotnet/cs/ in the TUnit.AspNetCore nupkg
• 21/21 analyzer tests pass (net9.0)

[claude]

TUnit0064 Analyzer + Code Fix — Review

This is a well-structured addition that follows the existing analyzer/codefixer patterns in the repo. The analyzer logic is sound, the diagnostic location is correct (base type, not class identifier), and the transitive-safety reasoning is clearly thought through. A few things worth checking before merge:

---

1. Code fix missing from versioned Roslyn packaging paths (potential gap)

In TUnit.AspNetCore.Core.csproj, the codefix DLL is only packed into analyzers/dotnet/cs:

<None Include="...TUnit.AspNetCore.Analyzers.CodeFixers.dll"
      Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />

But the analyzers also ship at versioned paths: analyzers/dotnet/roslyn4.14/cs, analyzers/dotnet/roslyn4.4/cs, and analyzers/dotnet/roslyn4.7/cs. The code fix provider references the analyzer's DiagnosticId at runtime to wire up, so the fixer DLL needs to be resolvable alongside whichever versioned analyzer is loaded. Whether NuGet's fallback convention resolves dotnet/cs as a base path for all Roslyn variants is worth explicitly verifying — the existing TUnit.Analyzers.CodeFixers packaging is the right reference to confirm against.

---

2. AddUsingIfMissing only inspects compilation-unit-level usings

if (compilationUnit.Usings.Any(u => u.Name?.ToString() == namespaceName))
    return compilationUnit;

CompilationUnitSyntax.Usings only covers top-level using directives. If the user writes:

namespace MyApp
{
    using TUnit.AspNetCore; // inside a namespace block
    
    public class MyFactory : WebApplicationFactory<Program> { }
}

The code fix will add a second using TUnit.AspNetCore; at the top of the file. A more robust check would also scan NamespaceDeclarationSyntax.Usings in the compilation unit. This is an edge case but worth handling cleanly, especially since this fix will be applied automatically.

---

3. Missing code fix test: no-duplicate-using when already present

The single code fix test (Rewrites_Base_Type_To_TestWebApplicationFactory) only covers the case where there is no pre-existing using TUnit.AspNetCore;. There is no test verifying that the fix does not insert a duplicate when the using already exists:

// fixedSource should not gain a second using
using TUnit.AspNetCore;

public class MyFactory : {|#0:Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory<Program>|} { }

Given that the fix-all provider (BatchFixer) may apply this across multiple files, a duplicate-using bug here would be more disruptive than a single-file typo.

---

4. Minor: AddUsingIfMissing appends at the end of the using list

compilationUnit.AddUsings(newUsing) appends the new directive after existing ones. Most C# style guides and IDE formatters sort usings alphabetically — TUnit.AspNetCore would typically sort after System.* but before project-local namespaces. This is purely cosmetic (the Formatter.Annotation on the replacement node handles indentation, but not using order), but users on projects with enforced using-sort rules may see a follow-up Roslyn fix applied on top. Not a blocker, just worth being aware of.

---

Summary

The core analyzer logic, diagnostic placement, and guard against TestWebApplicationFactory itself are all correct. The packaging gap (#1) is the most important thing to verify before shipping — if the code fix doesn't load in the versioned Roslyn scenarios, users will see the squiggle but no quick-fix lightbulb, which is a worse UX than no fix at all. The duplicate-using edge case (#2 / #3) is the other thing worth tightening up with a test.

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 minor

Alerts:
⚠ 1 issue (≤ 0 issues of at least minor severity)

Results:
1 new issue

Category	Results
CodeStyle	1 minor

View in Codacy

🟢 Metrics 40 complexity

Metric	Results
Complexity	40

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[thomhurst]

Thanks for the review. Responses:

1. Packaging: The single analyzers/dotnet/cs path matches how TUnit.Analyzers.CodeFixers is already packed in TUnit.Core.csproj (line 48-50) — the versioned paths only host the analyzer DLL itself, and NuGet falls back from roslynX.Y/cs to dotnet/cs for the codefixer. Following the established pattern, so leaving as-is.

2 & 3. Namespace-scoped usings + test: Real gap, fixed in 5aeb7cd. AddUsingIfMissing now also scans BaseNamespaceDeclarationSyntax.Usings (and aliases/static directives are excluded from the match). Added two tests: one for pre-existing top-level using, one for namespace-scoped.

4. Using order: Agreed — purely cosmetic and downstream formatters sort. Leaving to avoid scope creep.

23/23 tests pass on net9.0.

[claude]

PR Review: TUnit0064 — Direct WebApplicationFactory Inheritance Analyzer + Code Fix

This is a well-executed addition that follows the existing analyzer/code-fixer patterns cleanly. The diagnostic rationale is sound (silent loss of tracing, log correlation, and TestContext.Current) and the implementation correctly avoids false positives.

---

What works well

Analyzer design: Using RegisterCompilationStartAction to resolve WebApplicationFactory and TestWebApplicationFactory once per compilation (rather than once per symbol) is the right approach and avoids repeated lookups.

Diagnostic location: Reporting at baseList.Types[0].GetLocation() instead of the class identifier is deliberate and correct — the squiggle appears exactly where the problematic inheritance is declared.

Transitive case: The early exit when baseType.OriginalDefinition != webApplicationFactory correctly handles chains like MyFactory : UserBase : TestWebApplicationFactory<T> without false positives.

Code fix robustness: Handling all three qualified name forms (GenericNameSyntax, QualifiedNameSyntax { Right: GenericNameSyntax }, AliasQualifiedNameSyntax) covers the realistic ways users would write the fully-qualified base type.

Using deduplication: ContainsUsingInNamespace correctly descends into BaseNamespaceDeclarationSyntax, which covers both block-scoped and file-scoped namespace declarations.

---

Issues / Concerns

1. Code fixer not bundled in Roslyn-version-specific paths (potential packaging gap)

The analyzer is packed at both:

• analyzers/dotnet/cs (generic fallback)
• analyzers/dotnet/roslyn4.14/cs (specific Roslyn version)

But the code fixer is only at:

<None Include=...TUnit.AspNetCore.Analyzers.CodeFixers.dll
      Pack=true PackagePath=analyzers/dotnet/cs />

IDEs and tooling that prefer the versioned path (e.g., JetBrains Rider picking roslyn4.14/cs) will find the analyzer but may not find the paired code fixer. The fix would be to also pack the code fixer at each versioned analyzer path, or confirm that NuGet's fallback-to-generic behavior covers this case.

---

2. Null-guard asymmetry for testWebApplicationFactory

When testWebApplicationFactory is null (i.e., TUnit.AspNetCore isn't in the compilation), the analyzer still fires the diagnostic. The code fix then adds using TUnit.AspNetCore; and rewrites the base type — but the type doesn't exist in the compilation, producing a new compile error. In practice this is fine because the analyzer is bundled within the package that includes TestWebApplicationFactory<T>, so both are always present together. But the intent isn't clear from the code itself:

// Current: silently warns even when TestWebApplicationFactory<T> is unavailable
if (testWebApplicationFactory is not null &&
    SymbolEqualityComparer.Default.Equals(type.OriginalDefinition, testWebApplicationFactory))
{
    return;
}

A comment explaining why the null case still warns would prevent future confusion, or alternatively bail early when null if you want to be conservative:

// If TestWebApplicationFactory<T> isn't in scope, nothing to migrate to — skip.
if (testWebApplicationFactory is null)
    return;

This would also make the code fixer safe to apply in any context.

---

3. Missing test: file-scoped namespace using deduplication

The ContainsUsingInNamespace logic handles FileScopedNamespaceDeclarationSyntax (via BaseNamespaceDeclarationSyntax), but there's no test for:

using TUnit.AspNetCore; // file-scoped namespace with inner using

namespace App;

public class MyFactory : WebApplicationFactory<Program> { }

If the code fix incorrectly duplicates the using in this case, it would be a silent regression. A test covering this form would lock in the expected behavior.

---

4. Missing test: partial class declarations

If someone splits their factory across two files and only one declares the base type, GetBaseTypeLocation iterates DeclaringSyntaxReferences and returns the first match. This is correct, but there's no test confirming the diagnostic fires exactly once (not twice) for a partial class.

---

Summary

The core logic is solid and the design is consistent with the rest of the analyzer suite. The packaging asymmetry (#1) is the only concern that could affect real users — worth verifying whether the generic analyzers/dotnet/cs path is sufficient or if a versioned path is needed for the code fixer. Items #2–4 are lower priority (defensive clarity + test coverage).

[thomhurst]

Thanks for round 2:

1. Packaging (re-raised): Same situation as the first review — the existing TUnit.Analyzers.CodeFixers ships only at analyzers/dotnet/cs (see TUnit.Core.csproj line 48-50) and works across all Roslyn variants. NuGet falls back from the versioned analyzer paths to the unversioned codefixer path. Matching the established pattern, not changing.

2. Null-guard asymmetry: Good call. Fixed in cbdc125 — now bailing out at the compilation-start action when TestWebApplicationFactory<T> can't be resolved. That means the analyzer only fires when the code fix can actually apply. testWebApplicationFactory is now non-nullable in the symbol action.

3. File-scoped namespace test: Added Does_Not_Duplicate_Using_In_File_Scoped_Namespace. Verifier gained a stubsSource overload so the stubs can live in a separate compilation source (required because file-scoped namespace has to precede every member).

4. Partial class test: Added Warning_Fires_Once_For_Partial_Class. Diagnostic fires exactly once; GetBaseTypeLocation returns the first syntax reference with a base list.

25/25 tests pass on net9.0.

[claude]

Follow-up Review: TUnit0064 — All Prior Concerns Addressed

Reviewing the two follow-up commits (5aeb7cdeb491, cbdc125a2a89) against the issues raised in previous reviews.

---

Previous concerns — status

1. Code fixer not in Roslyn-versioned packaging paths
✅ This is a non-issue by design. Checking TUnit.Core.csproj, TUnit.Analyzers.CodeFixers is also only packed at analyzers/dotnet/cs — code fixers consistently use the generic path while only analyzers get versioned paths. The current approach matches the established repo pattern.

2. Null-guard asymmetry (testWebApplicationFactory is null)
✅ Fixed in cbdc125a2a89. The analyzer now bails out early when TestWebApplicationFactory<T> isn't in the compilation, so the fixer can never produce a broken-reference compile error.

3. Namespace-scoped using deduplication
✅ Fixed in 5aeb7cdeb491. ContainsUsingInNamespace now recurses into BaseNamespaceDeclarationSyntax (covers both block-scoped and file-scoped namespaces), and AddUsingIfMissing checks both compilationUnit.Usings and namespace members before inserting.

4. Missing test: file-scoped namespace deduplication
✅ Added: Does_Not_Duplicate_Using_In_File_Scoped_Namespace.

5. Missing test: partial class fires once
✅ Added: Warning_Fires_Once_For_Partial_Class.

---

One remaining minor observation

There's no test covering the case where WebApplicationFactory<T> is present but TestWebApplicationFactory<T> is not (i.e., the null-guard path added in cbdc125a2a89). This is a narrow scenario (possible only when someone references Microsoft.AspNetCore.Mvc.Testing without TUnit.AspNetCore), but a test like No_Warning_When_TestWebApplicationFactory_Not_In_Scope would lock in that behavior:

[Test]
public async Task No_Warning_When_TestWebApplicationFactory_Not_In_Scope()
{
    // Only stub WebApplicationFactory, not TestWebApplicationFactory
    await Verifier.VerifyAnalyzerAsync("""
        namespace Microsoft.AspNetCore.Mvc.Testing
        {
            public class WebApplicationFactory<T> where T : class { }
        }
        public class Program { }
        public class MyFactory : Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory<Program> { }
        """);
}

This is low priority — the fix is correct and the path is implicitly exercised — but the test would prevent a future refactor from re-introducing the issue silently.

---

Summary

All substantive concerns from the prior reviews have been addressed cleanly and correctly. The analyzer design, diagnostic placement, code fix robustness, and packaging are all solid. The PR is ready to merge — the null-guard test above is purely additive polish, not a blocker.