-
-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pester fails during code coverage setup if a hidden directory is included in CodeCoverage.Path #2327
Comments
Good catch! Looks like we currently ignore hidden items for both test files and CC paths, including hidden files when a folder is specified. What would be the desired behavior?
Leaning towards option 1 myself as I'd expect there's a reason someone would make items hidden in the first place. 🙂 |
1 sounds sensible to me. |
Hi A disadvantage or your item 1 suggest is that this means that all test folders following the recommended structure will have to be explicitly named, which makes it more of a chore.
Then currently, on windows I can either not specify a location at all and all my tests will run or simply Workable options for me would include:
My preference is for the first option, but regardless of which one is selected, the behaviour should be consistent across operating systems. Thanks |
Checklist
What is the issue?
I have a project where I'm using pester where I use a dot-prefixed folder to provide a sample in a directory to ensure it sorts first above a sequential list of numbers for other directory names, for example:
If I explicitly add all folders into the
CodeCoverage.Path
setting of the Pester configuration like so, specifying-Force
to ensure hidden folders are returned (because of the.
prefix):Then Pester fails before tests start to run with an error similar to the below:
Expected Behavior
Pester successfully runs code coverage and the tests.
Steps To Reproduce
No response
Describe your environment
From WSL on Windows 11 running Ubuntu 22.04:
This also occurs in a Linux container running Ubuntu in GitHub Actions, which is where I originally found the issue as I have a Windows development machine and the issue was not apparent there due to the different handling of folders with a
.
prefix.Possible Solution?
From a cursory look at the code pointed to by the stack trace, it looks like
-Force
would needed to be passed through to this call toGet-Item
so the directories/files are found?Pester/src/functions/Coverage.ps1
Line 231 in d81fdbc
The text was updated successfully, but these errors were encountered: