Azure Resources API (v4) internal tests #1288
Conversation
|
|
||
| /** | ||
| * A mock credential manager with the same implementation as `AzExtUUIDCredentialManager`, | ||
| * but with a public getter to inspect the UUIDs during test. |
There was a problem hiding this comment.
A less copy and paste mock would be possible if I extended from the AzExtUUIDCredentialManager directly, but the map would need to be protected not private for me to be able to access it.
MicroFish91
changed the title
test/global.test.ts
Outdated
| // Initialize test API - this caches it for use throughout tests | ||
| await getTestApi(); | ||
| const testApi: TestApi = await getTestApi(); | ||
| registerUIExtensionVariables(testApi.extensionVariables.getUI()); |
There was a problem hiding this comment.
Is there a way around needing to do registerUIExtensionVariables? Elsewhere for example, we just expose from the extension what is needed (only when running tests).
There was a problem hiding this comment.
TLDR:
I'm not personally sure how to do it otherwise, so I might need help coming up with a better way.
Long story:
I think what's happening is I'm calling createApiProvider during tests which is exported from utils. createApiProvider calls into getPackageInfo (also in utils) which calls ext.context which is uninitialized and throws an error.
At this point ext.context is uninitialized because we haven't registered the extension vars at any point during testing. I assume registrations in activation.ts won't count since they probably live in a separate process.
I was looking around at some other extensions because I do see that we get by with not always registering in global.test.ts. I'm currently looking at Functions, and though I don't see a registration call, I'm thinking maybe we're just never calling into the actual methods that leverage these variables?
Like the most obvious culprit for me to follow-up on was showQuickPick because we call that all the time. But then I thought about it some more, and likely showQuickPick is only getting called in the actual extension context (where it has already been successfully registered) and not the test context.
Just as a quick reference, these are the common spots where these variables are used from utils. It doesn't look like there are that many files where they're used, so maybe it's possible we're just accidentally getting away with not registering in some extensions since we just rarely use these outside of the normal extension context.
There was a problem hiding this comment.
Ah, this looks very similar to what I had to do to make the tests in utils/azure/appservice work. Those are in a truly extensionless environment so it's sorta inevitable there. But, it may make sense to do the same here.
testGlobalSetup.ts: https://github.com/microsoft/vscode-azuretools/blob/main/utils/src/dev/testGlobalSetup.ts
Used here: https://github.com/microsoft/vscode-azuretools/blob/main/utils/test/global.test.ts
Somewhat more advanced example of usage here: https://github.com/microsoft/vscode-azuretools/blob/a6733fc8b101519db04dd98832359faa167a6fd3/appservice/test/global.test.ts
For them it was a similar story--getPackageInfo was getting called. It was sufficient to fill in just a small subset of what would normally be there for the extension variables.
MicroFish91
force-pushed
the
mwf/v4-tests
branch
from
9314afc to
56385e1
Compare
No description provided.