feat: add source-generated assertions for various types using AssertionFrom attributes

[thomhurst]

No description provided.

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review Complete ✅

Reviewing the source-generated assertions implementation for various types.

Review Checklist:

• Read repository guidelines (CLAUDE.md)
• Examine main generator changes in AssertionMethodGenerator.cs
• Review new assertion extension files
• Check AssertionFromAttribute modifications
• Analyze dual-mode implementation compliance
• Assess code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage needs

---

🎯 Summary

This PR implements source-generated assertions for various .NET types using the enhanced AssertionFromAttribute. The implementation adds assertion methods for BigInteger, Cookie, double, float, HttpResponseMessage, Nullable, Rune, and ValueTask types.

✅ Positive Aspects

1. Excellent Code Quality & Modern Patterns

• Modern C# syntax: Uses file-scoped namespaces, collection expressions, and pattern matching throughout
• Clean declarative approach: The attribute-based generation is elegant and maintainable
• Consistent patterns: All new assertion files follow the same structure and naming conventions
• Good documentation: Each file has comprehensive XML documentation explaining purpose and usage

2. Comprehensive Feature Implementation

• Generic AssertionFromAttribute: Supports both generic and non-generic variants properly
• Enhanced attribute properties: Well-designed properties like CustomName, NegateLogic, ExpectationMessage
• Framework targeting: Proper use of preprocessor directives for .NET version-specific features
• Broad type coverage: Covers important .NET types that users frequently need to assert on

3. Generator Robustness

• Error handling: Skips error symbols gracefully with diagnostic reporting
• Generic type support: Handles unbound generic types, method type parameters, and constraints correctly
• Multiple overload support: Generates appropriate methods for different parameter combinations
• Property vs method handling: Correctly differentiates between property getters and methods

4. Performance Considerations

• Minimal allocations: Uses StringBuilder for code generation, proper parameter handling
• Caching logic: The generator includes deduplication logic to avoid generating duplicate classes
• Hot path awareness: The generated code follows TUnit's performance patterns

⚠️ Areas for Improvement

1. Critical: Dual-Mode Implementation Gap

BLOCKER: This PR violates Rule 1 from CLAUDE.md - missing reflection mode implementation.

Issue: The source generator creates assertions, but there's no corresponding implementation in TUnit.Engine for reflection mode. This means:

• Tests using reflection mode won't have access to these assertions
• Dual-mode parity is broken
• CI will likely fail when testing both execution modes

Required Fix: Implement reflection-based discovery for classes marked with AssertionFromAttribute in TUnit.Engine.

2. Missing Snapshot Updates

Important: Changes to source generator output require snapshot test updates.

Required Actions:

dotnet test TUnit.Core.SourceGenerator.Tests
# Review .received.txt files for new generated code
# Accept snapshots if correct
for f in *.received.txt; do mv "$f" "${f%.received.txt}.verified.txt"; done

3. Test Coverage Gaps

• No integration tests: Need tests verifying the generated assertions work correctly
• No dual-mode tests: Must test both source-gen and reflection modes produce identical behavior
• Missing error scenarios: Need tests for invalid method references, type errors, etc.

4. Potential Generator Issues

Null Reference Risk (Line 576):

// AssertionMethodGenerator.cs:576
var genericConstraints = CollectGenericConstraints(staticMethod);

If staticMethod is null, this could throw. Add null checks.

Performance in Hot Path (Lines 373-391):

The method lookup logic uses LINQ extensively:

var methodMembers = attributeData.ContainingType.GetMembers(attributeData.MethodName)
    .OfType<IMethodSymbol>()
    .Where(m => /* complex conditions */)
    .OrderBy(m => m.Parameters.Length)
    .ToArray();

Recommendation: Consider caching method lookups for frequently referenced types.

5. API Design Concerns

Generic Type Parameter Handling:

The RequiresGenericTypeParameter flag seems specific to Enum.IsDefined. Consider if this pattern will scale to other similar scenarios.

Nullable Reference Handling (Lines 742-755):

The null check logic is complex and might miss edge cases. The fallback to method name checking (IsNullOrEmpty, IsNullOrWhiteSpace) is brittle.

6. Minor Issues

Inconsistent Generic Syntax:

• Some files use AssertionFrom<T> (preferred)
• Others use AssertionFrom(typeof(int?), ...)

Example in NullableAssertionExtensions.cs:9:

[AssertionFrom(typeof(int?), nameof(Nullable<int>.HasValue), ExpectationMessage = "have a value")]

Should be:

[AssertionFrom<int?>(nameof(Nullable<int>.HasValue), ExpectationMessage = "have a value")]

🔒 Security Assessment

• Low risk: Source generation with type validation
• No dynamic code execution: All generated code is statically analyzable
• Proper input validation: Type checks prevent invalid method references

🚀 Performance Assessment

• Generator performance: Acceptable overhead during compilation
• Runtime performance: Generated assertions should be as fast as hand-written ones
• Memory usage: Minimal additional allocations in assertion execution

📋 Required Actions Before Merge

High Priority (Blockers):

1. Implement reflection mode support in TUnit.Engine
2. Update snapshot tests for source generator changes
3. Add integration tests for all new assertion types
4. Add dual-mode tests verifying identical behavior

Medium Priority:

1. Fix nullable method parameter handling for better edge case coverage
2. Add null checks in generator for robustness
3. Standardize generic syntax across all assertion files
4. Add error diagnostics for invalid attribute usage

Low Priority:

1. Performance optimization of method lookup logic
2. Enhanced error messages for generator diagnostics
3. Additional documentation for complex scenarios

---

🎯 Recommendation

Overall: This is a well-designed feature that adds significant value to TUnit's assertion library. The code quality is high and follows TUnit's conventions well.

Verdict: ⚠️ Needs Work - The dual-mode implementation gap is a critical blocker that must be resolved before merge.

Once the reflection mode implementation is added and snapshot tests are updated, this will be an excellent addition to TUnit.

---

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review Complete ✅

Reviewing the source-generated assertions implementation for various types.

Review Checklist:

• Read repository guidelines (CLAUDE.md)
• Examine main generator changes in AssertionMethodGenerator.cs
• Review new assertion extension files
• Check AssertionFromAttribute modifications
• Analyze dual-mode implementation compliance
• Assess code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage needs

---

🎯 Summary

This PR implements source-generated assertions for various .NET types using the enhanced AssertionFromAttribute. The implementation adds assertion methods for BigInteger, Cookie, double, float, HttpResponseMessage, Nullable, Rune, and ValueTask types.

✅ Positive Aspects

1. Excellent Code Quality & Modern Patterns

• Modern C# syntax: Uses file-scoped namespaces, collection expressions, and pattern matching throughout
• Clean declarative approach: The attribute-based generation is elegant and maintainable
• Consistent patterns: All new assertion files follow the same structure and naming conventions
• Good documentation: Each file has comprehensive XML documentation explaining purpose and usage

2. Comprehensive Feature Implementation

• Generic AssertionFromAttribute: Supports both generic and non-generic variants properly
• Enhanced attribute properties: Well-designed properties like CustomName, NegateLogic, ExpectationMessage
• Framework targeting: Proper use of preprocessor directives for .NET version-specific features
• Broad type coverage: Covers important .NET types that users frequently need to assert on

3. Generator Robustness

• Error handling: Skips error symbols gracefully with diagnostic reporting
• Generic type support: Handles unbound generic types, method type parameters, and constraints correctly
• Multiple overload support: Generates appropriate methods for different parameter combinations
• Property vs method handling: Correctly differentiates between property getters and methods

4. Performance Considerations

• Minimal allocations: Uses StringBuilder for code generation, proper parameter handling
• Caching logic: The generator includes deduplication logic to avoid generating duplicate classes
• Hot path awareness: The generated code follows TUnit's performance patterns

⚠️ Areas for Improvement

1. Critical: Dual-Mode Implementation Gap

BLOCKER: This PR violates Rule 1 from CLAUDE.md - missing reflection mode implementation.

Issue: The source generator creates assertions, but there's no corresponding implementation in TUnit.Engine for reflection mode. This means:

• Tests using reflection mode won't have access to these assertions
• Dual-mode parity is broken
• CI will likely fail when testing both execution modes

Required Fix: Implement reflection-based discovery for classes marked with AssertionFromAttribute in TUnit.Engine.

2. Missing Snapshot Updates

Important: Changes to source generator output require snapshot test updates.

Required Actions:

dotnet test TUnit.Core.SourceGenerator.Tests
# Review .received.txt files for new generated code
# Accept snapshots if correct
for f in *.received.txt; do mv "$f" "${f%.received.txt}.verified.txt"; done

3. Test Coverage Gaps

• No integration tests: Need tests verifying the generated assertions work correctly
• No dual-mode tests: Must test both source-gen and reflection modes produce identical behavior
• Missing error scenarios: Need tests for invalid method references, type errors, etc.

4. Potential Generator Issues

Null Reference Risk (Line 576):

// AssertionMethodGenerator.cs:576
var genericConstraints = CollectGenericConstraints(staticMethod);

If staticMethod is null, this could throw. Add null checks.

Performance in Hot Path (Lines 373-391):

The method lookup logic uses LINQ extensively:

var methodMembers = attributeData.ContainingType.GetMembers(attributeData.MethodName)
    .OfType<IMethodSymbol>()
    .Where(m => /* complex conditions */)
    .OrderBy(m => m.Parameters.Length)
    .ToArray();

Recommendation: Consider caching method lookups for frequently referenced types.

5. API Design Concerns

Generic Type Parameter Handling:

The RequiresGenericTypeParameter flag seems specific to Enum.IsDefined. Consider if this pattern will scale to other similar scenarios.

Nullable Reference Handling (Lines 742-755):

The null check logic is complex and might miss edge cases. The fallback to method name checking (IsNullOrEmpty, IsNullOrWhiteSpace) is brittle.

6. Minor Issues

Inconsistent Generic Syntax:

• Some files use AssertionFrom<T> (preferred)
• Others use AssertionFrom(typeof(int?), ...)

Example in NullableAssertionExtensions.cs:9:

[AssertionFrom(typeof(int?), nameof(Nullable<int>.HasValue), ExpectationMessage = "have a value")]

Should be:

[AssertionFrom<int?>(nameof(Nullable<int>.HasValue), ExpectationMessage = "have a value")]

🔒 Security Assessment

• Low risk: Source generation with type validation
• No dynamic code execution: All generated code is statically analyzable
• Proper input validation: Type checks prevent invalid method references

🚀 Performance Assessment

• Generator performance: Acceptable overhead during compilation
• Runtime performance: Generated assertions should be as fast as hand-written ones
• Memory usage: Minimal additional allocations in assertion execution

📋 Required Actions Before Merge

High Priority (Blockers):

1. Implement reflection mode support in TUnit.Engine
2. Update snapshot tests for source generator changes
3. Add integration tests for all new assertion types
4. Add dual-mode tests verifying identical behavior

Medium Priority:

1. Fix nullable method parameter handling for better edge case coverage
2. Add null checks in generator for robustness
3. Standardize generic syntax across all assertion files
4. Add error diagnostics for invalid attribute usage

Low Priority:

1. Performance optimization of method lookup logic
2. Enhanced error messages for generator diagnostics
3. Additional documentation for complex scenarios

---

🎯 Recommendation

Overall: This is a well-designed feature that adds significant value to TUnit's assertion library. The code quality is high and follows TUnit's conventions well.

Verdict: ⚠️ Needs Work - The dual-mode implementation gap is a critical blocker that must be resolved before merge.

Once the reflection mode implementation is added and snapshot tests are updated, this will be an excellent addition to TUnit.

---

View job