hey pulumiers... I'm using the automation API to w...
# general
d
hey pulumiers... I'm using the automation API to write integration tests - but I'm still in the "find out what works" phase of the test creation. My stacks and ideas are solid enough, but little things break, like the length of resource names are too long or accidentally contain a character that isn't allowed within a resource name for a cloud object. What techniques are you using to speed the dev cycle up? Is there any collection of "good practises" around? One blocker I've got is that I'm using the deployment instance stack name as a source of uniqueness in my resource names - which of course doesn't exist unless the pulumi runasync() is called - which means I have to instantiate a stack / deploy it - terribly slow. Any tips or pointers to better ways of testing are appreciated!
e
One blocker I've got is that I'm using the deployment instance stack name as a source of uniqueness in my resource names
Why are you not relying on pulumi to autoname things?
which of course doesn't exist unless the pulumi runasync() is called
Can't you use mock stacks for this?
l
Are you running unit tests (with "mock" stacks) first, before your real-stack integration tests? I prefer the unit-style tests within Pulumi, and then integration-style tests outside Pulumi (using the normal SDKs of the cloud).
d
Not yet - but that seems very appealing... I need to look that up - are there examples you could point me at (I don't care which language, I'll adapt/look). Thank you!
e