Skip to content
This repository has been archived by the owner on Jun 13, 2024. It is now read-only.

Expected location (Diagnostics) #2

Open
RamblingCookieMonster opened this issue Nov 11, 2015 · 2 comments
Open

Expected location (Diagnostics) #2

RamblingCookieMonster opened this issue Nov 11, 2015 · 2 comments
Labels

Comments

@RamblingCookieMonster
Copy link

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!

@JamesWTruher
Copy link
Contributor

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.

@RamblingCookieMonster
Copy link
Author

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants