Skip to content

fix(assertions): emit auto-generated header in MethodAssertionGenerator output#5796

Merged
thomhurst merged 2 commits intothomhurst:mainfrom
JohnVerheij:fix/generateassertion-auto-generated-header
Apr 30, 2026
Merged

fix(assertions): emit auto-generated header in MethodAssertionGenerator output#5796
thomhurst merged 2 commits intothomhurst:mainfrom
JohnVerheij:fix/generateassertion-auto-generated-header

Conversation

@JohnVerheij
Copy link
Copy Markdown
Contributor

@JohnVerheij JohnVerheij commented Apr 30, 2026

Description

Adds // <auto-generated/> + #pragma warning disable to the file headers emitted by MethodAssertionGenerator, AssertionExtensionGenerator, and AssertionMethodGenerator, completing the convention already used by TUnit.Core.SourceGenerator/CodeWriter.cs:25-26, MockGenerator, and ShouldExtensionGenerator. Without this header, consumer projects with <GenerateDocumentationFile>true</GenerateDocumentationFile> and <TreatWarningsAsErrors>true</TreatWarningsAsErrors> fail to build because every [GenerateAssertion] site produces CS1591 warnings on the generated public types and members. Same problem class as #3031, resolved for DataSourceHelpersGenerator in #3163.

Related Issue

Closes #5795. Related to #3031 (same problem class) and #3163 (prior fix for DataSourceHelpersGenerator).

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Performance improvement
  • Refactoring (no functional changes)

Checklist

Required

  • I have read the Contributing Guidelines
  • If this is a new feature, I started a discussion first and received agreement
  • My code follows the project's code style (modern C# syntax, proper naming conventions)
  • I have written tests that prove my fix is effective or my feature works

TUnit-Specific Requirements

  • Dual-Mode Implementation: If this change affects test discovery/execution, I have implemented it in BOTH:
    • Source Generator path (TUnit.Core.SourceGenerator)
    • Reflection path (TUnit.Engine)
  • Snapshot Tests: If I changed source generator output or public APIs:
    • I ran TUnit.Core.SourceGenerator.Tests and/or TUnit.PublicAPI tests
    • I reviewed the .received.txt files and accepted them as .verified.txt
    • I committed the updated .verified.txt files
  • Performance: If this change affects hot paths (test discovery, execution, assertions):
    • I minimized allocations and avoided LINQ in hot paths
    • I cached reflection results where appropriate
  • AOT Compatibility: If this change uses reflection:
    • I added appropriate [DynamicallyAccessedMembers] annotations
    • I verified the change works with dotnet publish -p:PublishAot=true

Testing

  • All existing tests pass (dotnet test)
  • I have added tests that cover my changes
  • I have tested both source-generated and reflection modes (if applicable)

Additional Notes

Each generator change matches TUnit.Core.SourceGenerator/CodeWriter.cs:25-26 (2 lines per generator, 6 lines total). New XmlDocsRegressionTests compiles MethodAssertionGenerator output through Roslyn under strict documentation mode and asserts no CS1591 fires; this catches regressions if the header is ever removed or moved. Existing snapshot tests for AssertionExtensionGenerator and AssertionMethodGenerator similarly catch any regression on those generators via baseline mismatches.

Dual-Mode, Performance, and AOT items left unchecked because the change only affects the file header emitted by the source generator — no test discovery, hot-path, or reflection involvement. The "tested in both modes" item is similarly N/A: the generator output is consumed by both modes identically, and the change doesn't alter discovery or execution paths.

@codacy-production
Copy link
Copy Markdown

codacy-production Bot commented Apr 30, 2026

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.

Copy link
Copy Markdown
Contributor

@claude claude Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Clean, well-targeted bug fix. The 2-line header addition to MethodAssertionGenerator correctly addresses CS1591 build failures for consumer projects with <GenerateDocumentationFile>true</GenerateDocumentationFile> and <TreatWarningsAsErrors>true</TreatWarningsAsErrors>.

What's good

  • Minimal and correct fix: The change is exactly 2 lines at the right location, and the ordering (// <auto-generated/>#pragma warning disable#nullable enable) matches the established convention in TUnit.Core.SourceGenerator/CodeWriter.cs:25-26.
  • Snapshot files properly updated: All 127 .verified.txt files are updated consistently with the 2-line header prepended, which is the right way to update snapshot tests in this project.
  • Smart regression test: XmlDocsRegressionTests.cs takes a particularly good approach — it compiles generated output through Roslyn using DocumentationMode.Diagnose (strict mode) and asserts zero CS1591 diagnostics. This will reliably catch any future regression if the header is removed or mis-ordered.

One thing to follow up on

Two other generators in the same package also lack the auto-generated header:

TUnit.Assertions.SourceGenerator/Generators/AssertionExtensionGenerator.cs:136  # starts with #nullable enable
TUnit.Assertions.SourceGenerator/Generators/AssertionMethodGenerator.cs:346     # starts with #nullable enable

AssertionExtensionGenerator even emits explicit XML doc comments (/// <summary>, /// <remarks> etc.) on its generated public members, so it won't trigger CS1591 there. But if either generator ever gains new public members without docs, or consumers have stricter tooling that flags auto-generated code separately, the same problem class will recur. A follow-up to bring those two generators in line with this fix would make the whole package consistent.

This is not a blocker for this PR since the scope here is correctly limited to MethodAssertionGenerator as reported in #5795.

Summary

This is a solid, well-scoped fix with appropriate test coverage. The approach is correct and the regression test is a nice addition to the test suite.

@thomhurst
Copy link
Copy Markdown
Owner

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: MethodAssertionGenerator output triggers CS1591 in consumers with GenerateDocumentationFile=true

2 participants