This message was deleted Pulumi Community #general

Join Slack

This message was deleted.

# general

sparse-intern-71089

04/10/2019, 11:53 AM

This message was deleted.

👍 3

bitter-oil-46081

04/10/2019, 6:29 PM

We don't have as nice a story as we'd like yet. The long term tracking issue is: https://github.com/pulumi/pulumi/issues/2287, which tracks being able to write tests inside the source language itself (i.e. using mocha or something to write tests in JS which let you control deploying a stack, asking questions about the resources deployed, etc). What we use today is we have a small framework written in golang that can use

go test

to drive the lifecycle of a stack. You can see some examples here: https://github.com/pulumi/pulumi-aws/blob/master/examples/examples_test.go The core of the framework is here: https://github.com/pulumi/pulumi/blob/master/pkg/testing/integration/program.go#L417 and basically it handles running a bunch of invocations of

pulumi

for a given program to create a stack, deploy it and then destroy it. There are hooks such that you can preform extra validation after the stack has been deployed (for example, hitting a HTTP endpoint it deploys to ensure it actually gives you the correct response)

bitter-oil-46081

04/10/2019, 6:30 PM

This is what we've been using today, since it is just running

pulumi

behind the scenes, your infrastructure can be written in any language, but the test itself has to be written in golang and invoked with

go test

bitter-oil-46081

04/10/2019, 6:34 PM

Would love to know if something like the above fits with the kind of testing you want to do. I expect what we will end up doing in 2287 will look similar, but we'll probably also expose the more primitive pulumi operations as well, so you can explicitly control the lifecycle if you want, but by default we'll probably focus on making "start from an empty stack, run a program to update it, run some custom user specified validation, and then destroy the stack"

👍 1

straight-jordan-23612

04/10/2019, 8:10 PM

thanks for all the information. I am not a golang coder so that will present some opportunities to read through.

modern-bear-85657

04/10/2019, 8:36 PM

@bitter-oil-46081 Is there a ‘no-op’ mode so that functions that build resources could be stubbed/mocked?

Open in Slack

Previous Next