Open RamblingCookieMonster opened 9 years ago
That's definitely a reasonable request - my main thought was to make it distinguished from other more feature/unittest type tests, and to make it a bit more discoverable. Your point about the complications with regard to segregating these tests from the more feature/unittest level is quite valid. Running feature tests via Invoke-Pester would require the including the file(s) in which the feature tests reside, otherwise the scenario and feature tests would all be run.
Another thing that does concern me is that I saw this as way to distribute scenario tests which were not associated with any actual PowerShell module. I thought it would be perfectly reasonable to distributed validators that had no other associated PowerShell code, and I was thinking that over time, that might even be the preponderance of validators that don't have associated PS Modules, thus I wanted to reduce the burden/directory structure.
Interesting idea, I could see that being quite handy as a framework for audits, reports, and various other assertions.
A potential workaround might be to allow another parameter/parameterset that points to folder containing the simple/comprehensive subfolders, rather than hard coding /diagnostics?
Anyhow, I don't have a strong opinion, just wanted to bring this up before the ecosystem / community use grows.
Cheers!
Hi all!
Repositories are filling up with more and more objects at the root. CI/CD config files, Tests folders, and more.
Would it be worth nesting Diagnostics under an existing norm, perhaps \Repository\Tests, rather than adding a folder to the repository root?
I'm assuming there might be complications to be addressed (i.e. invoking pester without executing operations tests, if that is desired), but avoiding the clutter might be helpful.
Cheers!