fix(assertions): emit auto-generated header in MethodAssertionGenerator output#5796
Conversation
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.
There was a problem hiding this comment.
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 inTUnit.Core.SourceGenerator/CodeWriter.cs:25-26. - Snapshot files properly updated: All 127
.verified.txtfiles 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.cstakes a particularly good approach — it compiles generated output through Roslyn usingDocumentationMode.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.
…erator and AssertionMethodGenerator
|
Thanks! |
Description
Adds
// <auto-generated/>+#pragma warning disableto the file headers emitted byMethodAssertionGenerator,AssertionExtensionGenerator, andAssertionMethodGenerator, completing the convention already used byTUnit.Core.SourceGenerator/CodeWriter.cs:25-26,MockGenerator, andShouldExtensionGenerator. 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 forDataSourceHelpersGeneratorin #3163.Related Issue
Closes #5795. Related to #3031 (same problem class) and #3163 (prior fix for
DataSourceHelpersGenerator).Type of Change
Checklist
Required
TUnit-Specific Requirements
TUnit.Core.SourceGenerator)TUnit.Engine)TUnit.Core.SourceGenerator.Testsand/orTUnit.PublicAPItests.received.txtfiles and accepted them as.verified.txt.verified.txtfiles[DynamicallyAccessedMembers]annotationsdotnet publish -p:PublishAot=trueTesting
dotnet test)Additional Notes
Each generator change matches
TUnit.Core.SourceGenerator/CodeWriter.cs:25-26(2 lines per generator, 6 lines total). NewXmlDocsRegressionTestscompilesMethodAssertionGeneratoroutput 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 forAssertionExtensionGeneratorandAssertionMethodGeneratorsimilarly 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.