Tests ARM, test case for ExtensionResource

[v-hongli1]

• ARM, test case for ExtensionResource #689

Cadl Ranch Contribution Checklist:

• I have written a scenario spec
• I have meaningful @scenario names. Someone can look at the list of scenarios and understand what I'm covering.
• I have written a mock API
• I have used @scenarioDocs for extra scenario description and to tell people how to pass my mock api check.

[iscai-msft]

nit: do we need ExtensionsResources, or is just Extensions ok bc it's in the Resources subspace

[XiaofeiCao]

Extension is good.

Glad you brought it up. In fact, I revisited our existing ARM cases:

Some of them contain duplicate like this, and some not appropriate, e.g. ManagedIdentityTrackedResources..
I've made a refactor PR to decouple SDK generated interface name with the scenarioName(it shouldn't affect existing generated SDKs):
#714

I had to use clientName to achieve that, as @scenario("xx") on the interface require extra mock tests for it.. Let me know if there are better solutions.

[iscai-msft]

Sorry I'm confused why you would need to use clientName. Can you clarify what is failing / needing extra tests because that shouldn't be happening. Here's an example of a renaming pr, if that helps

[v-hongli1]

Fixed by commit 8ca02c5

[XiaofeiCao]

Thanks, it's mainly because that I don't want to break existing generated SDKs from current cadl-ranch. We already have several languages wrote test for generated code.
Wonder if there's better way to achieve that rather than @clientName..

[iscai-msft]

In cases like these, we should go ahead and break. To do so, make sure everyone is aware of this issue, and that the PR has a minor version bump. Writing a mitigation guide (can just be a few lines: change x import to x import) is also very welcome.

[XiaofeiCao]

@iscai-msft May I know the concern of @clientName? There's one more potential use case: #714 (comment)

[iscai-msft]

somehow I totally missed this comment, my bad. The concern is that we're using @clientName to get around breaking cadl-ranch, and we're ok breaking cadl-ranch as long as everyone is aware. It adds technical debt and also makes the tests not as atomic: we aren't explicitly testing @clientName here so we shouldn't be using it