[Feature Request]: Align parameter files naming and scenarios

[eriqua]

Description

Align on the different use cases we want to cover in our module tests and reflect that in the parameter naming convention. For instance:

• modules covering multiple services should cover all test scenarios
  • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.parameters.json and face.parameters.json
• always include a min.parameters.json to cover only required parameters. For modules covering multiple services this could be duplicated if different services lead to different implementations.
  • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.min.parameters.json and face.min.parameters.json
• all modules providing cmk functionality should include a encr.parameters.json (or cmk.parameters.json). For modules covering multiple services this could be duplicated if different services lead to different implementations.

  Discussion needed: we could go for either a "always use encr.parameters.json" for consistency and to clearly show shorter specific examples in the readme or "use it only if required due to incompatibility with other settings" to instead try to include all possible features in the main parameters.json. The latter approach would probably be preferable considering the new dependencies approach. In either case update the Wiki as needed.

• all modules providing networking functionalities ahould include a net.parameters.json (or similar). For modules covering multiple services this could be duplicated if different services lead to different implementations.

  Discussion needed: same as above.

---

Update: this is now related to main.test.bicep wrapper modules

[eriqua]

Related to #401 which would be the implementation out of this discussion. I'd also propose to rename current max.parameters.json (analysys services and API management) to parameters.json to have consistency throughout the repo for the main test file. This main test file is a good candidate to be used for the public Bicep registry contribution, so it makes sense to have a consistent naming for that one.

[rahalan]

Wiki also needs to be updated

[AlexanderSehr]

I wonder if this is still relevant given the AVM specs. Thoughts @eriqua?

[eriqua]

@AlexanderSehr I think this is more related to the implementation than it is on the specs definition. I wish that was already the case in AVM. Starting from "the defaults test should only include required parametes" 😄
Modules are still not covering the above 100%, but specs are covering almost all already. However the gap is more on making sure that related AVM specs are fullfilled than about improving the specs coverage.

[AlexanderSehr]

Closing as created as new issues in AVM