https://pulumi.com logo
Join Slack
Powered by
Are the test fakes (`pulumi.runtime.setMocks`) sup...
# typescript
l
Are the test fakes (
pulumi.runtime.setMocks
) supposed to be cleared manually? I'm writing test modules and expecting the Pulumi runtime to know about the resources created during calls to Mocha 
before()
and similar code, and the resources created during the test. Nothing else should exist. But I'm finding all resources there. Not just ones in the same file, but ones in completely unrelated files that are being run during the same call to 
npm run test
. Do I need to clear the fakes ("mocks") out? Or do I need to wrap every test module in a call to 
runInPulumiStack()
?
Seem to be a lot of gotchas in this area. 
runInPulumiStack()
can't wrap 
setMocks()
. I can't see a way to clear the fakes set up in 
setMocks()
. I might have to change 
npm run test
to run mocha once per .spec.ts file, instead of once.
I think to make our case work, we'd need to get rid of pulumi.runtime's shared state, and use a local variable that gets passed to all calls to Pulumi. Which is not a small job... So I'll have a look at running Mocha once per .spec.ts file, and having a completely new Pulumi engine each time.
It looks like the actual problem is that the object passed to 
setMocks
is visible across all test files and each call to 
setMocks
blats whatever was already in there. For example, if in a.spec.ts I call 
pulumi.runtime.setMocks({ newResource: new_resource_a; call: call_a; })
and in b.spec.ts I do same except with 
new_resource_b
and 
call_b
, then the tests in a.spec.ts see the "correct" resources but they've been processed by 
new_resource_b
and 
call_b
. I need to scope Pulumi (or at least its runtime) to a single file, since the implementations of those faking functions are contradictory and can't be merged.
I think I need to scope the top-level variable 
options
in runtime/settings.ts. I'm a JS/TS beginner, I don't know what to search for to figure out how to achieve that 😞
Ok got it sorted for now, though there is a minor risk of race conditions if run in parallel. I've moved setMocks to before(), instead of just at the top of the class. For now I'm running my tests serially and it's all good.
2 Views
Open in Slack
PreviousNext
Powered by