feat: support assembly-level [assembly: Repeat(N)] - #4753
Conversation
Code reviewPerformance Issue: Uncached Assembly Attribute in Hot PathFile: The assembly-level repeat count lookup at line 1066 is not cached, violating the Performance First rule from CLAUDE.md:
Why this matters:
Suggested approach: Add a cache for assembly-level repeat counts following the existing pattern in the file: // At class level (around line 32-35)privatestaticreadonlyConcurrentDictionary<Assembly,int?>_assemblyRepeatCountCache=new();// In BuildTestMetadata (around line 1064-1066)RepeatCount=testMethod.GetCustomAttribute<RepeatAttribute>()?.Times??testClass.GetCustomAttribute<RepeatAttribute>()?.Times??_assemblyRepeatCountCache.GetOrAdd(testClass.Assembly,static assembly =>assembly.GetCustomAttribute<RepeatAttribute>()?.Times),Why this is better:
This is the only issue found. The rest of the implementation correctly follows the dual-mode architecture and maintains proper precedence ordering. |
RepeatAttribute declares AttributeTargets.Assembly but neither the source generator nor the reflection engine checked assembly-level attributes. This adds assembly as the lowest-precedence fallback (method > class > assembly) in both ExtractRepeatCount overloads and the reflection discovery path. Also tighten all RepeatAttribute checks in the source generator to verify the attribute's containing namespace is TUnit.Core, preventing false matches against user-defined attributes with the same name. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
b2b3b09 to
3153980CompareUh oh!
There was an error while loading. Please reload this page.
Summary
RepeatAttributein both source generatorExtractRepeatCountoverloads and the reflection engine'sReflectionTestDataCollectorTest plan
RepeatTests.Testsnapshot test passes (existing behavior unchanged)RepeatTests.Assembly_Level_Repeatsnapshot test passes, verifyingRepeatCount = 3for inherited andRepeatCount = 1for method-level override🤖 Generated with Claude Code