feat: Added logic to find child modules when running Test-ModuleLocally -PesterTest

[anderseide]

Description

Changed logic in Test-ModuleLocally to detect child modules. Uses same code as in the GitHub Action at https://github.com/Azure/bicep-registry-modules/blob/main/.github/actions/templates/avm-validateModulePester/action.yml

Closes #3869

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[microsoft-github-policy-service]

Important

If this is a module-related PR, being submitted by the sole owner of the module, the AVM core team must review and approve it (as module owners can't approve their own PRs).

To indicate this PR needs the core team''s attention, apply the "Needs: Core Team 🧞" label!

The core team will only review and approve PRs that have this label applied!

[AlexanderSehr]

Good idea, thanks @anderseide,
the only thought that came to mind is whether we should provide a controlling parameter to tell the invocation whether you want to test the entire hierachy - or only the provided template.
Reason being: Modules like e.g. API Management or Storage Account are very big. And if you just want to work on a failing test, re-runs can become a bit painful time-wise (as some tests, e.g. the one for the readme, take a moment to execute).

Speaking of - but that may absolutely break the scope of this PR and should be a seperate one. If we merge this change in, I'd recommend to update the Set-ModuleReadMe script should not apply any updatestest's logic to provide morePreLoadedContentto theSet-ModuleReadMeinvocation. Specifically theCrossReferencedModuleList&TelemetryFileContentas done in theSet-AVMModule` script. This should then massively speed up these recursive tests added by this PR :)

[anderseide]

Added -PesterTestRecurse switch to the script as pr. first part of your comment.

I'm playing around with some Pester tests improvements in a separate branch. I'll have a look at speeding up the Set-ModuleReadMe test logic there

[anderseide]

Test single module file

Test-ModuleLocally -PesterTest -TemplateFilePath ./avm/res/web/site/main.bicep

Test module recursively, witch includes all child modules

Test-ModuleLocally -PesterTestRecurse -TemplateFilePath ./avm/res/web/site/main.bicep