Dynamically count expected rules in GetScriptAnalyzerRule test - #2167
Dynamically count expected rules in GetScriptAnalyzerRule test#2167Andy Jordan (andyleejordan) merged 1 commit into
Conversation
Sorry, something went wrong.
Replace hardcoded rule count with dynamic counting of [Export(typeof(I...Rule))] attributes in C# source files. This prevents the test from breaking every time a new rule is added.
There was a problem hiding this comment.
Pull request overview
Updates the Get-ScriptAnalyzerRule Pester test to avoid hardcoding the expected number of built-in rules by deriving the expected count dynamically from the repository’s C# rule sources.
Changes:
- Replaces the fixed expected rule count (72) with a dynamic count based on scanning Rules/**/*.cs for Export(typeof(I*Rule)) occurrences.
- Adds comments explaining the dynamic rule-counting approach.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Sorry, something went wrong.
| # Dynamically count the expected number of rules from source files | ||
| # by finding all C# files with [Export(typeof(I...Rule))] attributes | ||
| $rulesRoot = Resolve-Path "$PSScriptRoot/../../Rules" | ||
| $expectedNumRules = (Get-ChildItem -Path $rulesRoot -Filter '*.cs' -Recurse | | ||
| Select-String -Pattern 'Export\(typeof\s*\(I\w+Rule\)\)' | | ||
| Select-Object -ExpandProperty Path -Unique).Count |
There was a problem hiding this comment.
Wow bad Copilot, that suggestion would mean that we don't end up testing anything at all.
Sorry, something went wrong.
There was a problem hiding this comment.
(Claude did the actual PR...lol)
Sorry, something went wrong.
Christoph Bergmeister (bergmeister)
left a comment
There was a problem hiding this comment.
Nice addition but it can still be of value to keep a hard=coded check (in addition to this), how about we make it less troublesome by just asserting greater than instead of equals so this test doesn't need updating for every new rule?
Sorry, something went wrong.
Had Copilot do this:
Seems like it works. I noticed every time a PR that added a rule was merged, all PRs after it failed because this test had a hardcoded assumption.