Skip to content

testing-unit-cs-mocks: add example of mocking Invoke (data source) calls - #2975

Merged
jkodroff merged 2 commits into
masterfrom
jkodroff/azure-cs-unit-testing-invoke-mocks
Aug 28, 2026
Merged

testing-unit-cs-mocks: add example of mocking Invoke (data source) calls#2975
jkodroff merged 2 commits into
masterfrom
jkodroff/azure-cs-unit-testing-invoke-mocks

Conversation

@eon-pulumi-agent

@eon-pulumi-agent eon-pulumi-agent Bot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Fixes #1057.

Analysis

The repo did not yet have an example covering the specific pain point in #1057: mocking a data-source Invoke call (ListStorageAccountKeys) whose result contains a nested array of complex objects (StorageAccountKeyResponse). The existing testing-unit-cs-mocks example only demonstrated mocking NewResourceAsync; its CallAsync was an unused pass-through.

I confirmed (by running dotnet test against the current Pulumi/Pulumi.AzureNative packages) that the workaround discussed in the issue thread (hand-crafting a JsonElement) is no longer necessary. The mock infrastructure serializes whatever CallAsync returns the same way it serializes resource inputs/outputs, so a plain nested Dictionary<string, object> / List<object> — with keys matching the camelCase field names of the target type (creationTime, keyName, permissions, value) — is sufficient.

Separately, while building this example I found that Pulumi.AzureNative's Invoke(...) (Output-returning) overload can hang indefinitely under the mock test harness when its arguments depend on other resources' outputs (exactly the resourceGroupName/accountName pattern from the issue). Wrapping the equivalent InvokeAsync(...) call in Output.Tuple(...).Apply(...) — the same pattern the original reporter used — works reliably and is what this example now uses and documents.

Changes

  • testing-unit-cs-mocks/WebsiteStack.cs: retrieves the storage account's primary key via ListStorageAccountKeys, using the InvokeAsync + Output.Tuple(...).Apply(...) pattern, with a comment explaining why.
  • testing-unit-cs-mocks/Testing.cs: Mocks.CallAsync now mocks the azure-native:storage:listStorageAccountKeys token, showing the plain-Dictionary/List approach.
  • testing-unit-cs-mocks/WebsiteStackTests.cs: adds a test asserting on the mocked value.
  • testing-unit-cs-mocks/README.md: documents the pattern and answers the "how do I format StorageAccountKeyResponse" question directly.

Verification

Installed the .NET 8 SDK locally and ran dotnet test in testing-unit-cs-mocks:

Passed!  - Failed: 0, Passed: 6, Skipped: 0, Total: 6

(previously 5 tests; added 1)


Created with Eon

Extends the existing C# unit-testing mocks example with a demonstration
of mocking an azure-native Invoke (data source) call whose result
contains a nested array of complex objects: ListStorageAccountKeys,
the exact scenario reported in #1057.

- WebsiteStack.cs now retrieves the storage account's primary key via
  ListStorageAccountKeys, using the InvokeAsync + Output.Tuple(...).Apply(...)
  pattern (the Invoke(...) Output-returning overload can be unreliable
  when its arguments depend on other resources' outputs).
- Testing.cs's Mocks.CallAsync shows that plain nested
  Dictionary/List values (matching the camelCase field names of the
  target type) are sufficient to mock such calls - no JsonElement/JSON
  hand-crafting required.
- WebsiteStackTests.cs adds a test asserting on the mocked value.
- README.md documents the pattern.
@jkodroff

Copy link
Copy Markdown
Member

The failures are unrelated to this change. Merging.

@jkodroff
jkodroff merged commit 4eefa37 into master Aug 28, 2026
28 of 32 checks passed
@jkodroff
jkodroff deleted the jkodroff/azure-cs-unit-testing-invoke-mocks branch August 28, 2026 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add more examples for AzureNative C# UniteTesting.

2 participants