fix: adjust overload resolution priorities for member assertions

[thomhurst]

Fixes #3930

[claude]

Claude finished @thomhurst's task —— View job

---

PR Review: Fix overload resolution priorities for member assertions

Review Checklist:

• Read and understand the changed files
• Analyze code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage implications
• Verify alignment with TUnit coding standards

Summary

This PR adjusts the [OverloadResolutionPriority] attributes for multiple Member method overloads in AssertionExtensions.cs to fix issue #3930. The changes establish a clear hierarchy for overload resolution, prioritizing AOT-compatible strongly-typed overloads over legacy reflection-based ones.

Code Quality Assessment

✅ Strengths

1. Well-structured overload hierarchy: The new priority system follows a logical pattern:

   • Highest priority (3): Generic transformable overloads (TTransformed)
   • Medium priority (1-2): Specific type-preserving overloads
   • Lowest priority (-1 to 0): Legacy reflection-based overloads

2. AOT compatibility prioritization: The changes correctly favor AOT-compatible overloads over RequiresDynamicCode variants, which aligns with TUnit's performance-first philosophy.

3. Consistent documentation: All modified overloads maintain clear documentation about their purpose and AOT compatibility implications.

4. Proper API versioning: The snapshot files are correctly updated, following TUnit's mandatory snapshot testing practice.

⚠️ Areas of Concern

1. Missing priority on one overload: The generic Member<TObject, TMember> overload at line 531 previously had no explicit priority but now has [OverloadResolutionPriority(0)]. While this is good for clarity, it could potentially be a breaking change if code was relying on the default resolution behavior.

2. Complex overload matrix: With 7+ overloads for the Member method across different type scenarios, the resolution priority system is becoming complex. Consider if further consolidation is possible in future versions.

Security & Performance

• Security: ✅ No security concerns. Changes are limited to compile-time overload resolution.
• Performance: ✅ Positive impact - prioritizes AOT-compatible overloads which avoid reflection overhead.

Potential Issues

Low Risk: Behavioral Changes

The priority adjustments could theoretically change which overload gets selected in ambiguous scenarios. However:

• The changes appear to be moving toward more predictable, type-safe resolution
• Legacy overloads are still available for backward compatibility
• Documentation clearly indicates preferred usage patterns

Test Coverage

The API snapshot tests in both DotNet9_0 and DotNet10_0 are properly updated, ensuring the public API changes are tracked. The changes are purely attribute-based, so runtime behavior testing may not be strictly necessary, but integration tests covering the member assertion scenarios would be valuable.

TUnit Standards Compliance

✅ Fully compliant with TUnit development standards:

• Follows the snapshot testing requirements for public API changes
• Maintains AOT compatibility prioritization
• Uses proper modern C# attributes and patterns
• No performance regressions in hot paths

Recommendation

✅ APPROVE - This is a well-executed fix that improves overload resolution clarity while maintaining backward compatibility. The changes align with TUnit's AOT-first approach and follow all established patterns.

Minor Suggestions:

1. Consider adding a comment block above the Member method group explaining the overload priority strategy for future maintainers
2. Integration tests covering edge cases of member assertion overload selection would provide additional confidence

---