This message was deleted.

Our primary focus for testing currently has been on real-world testing - creating instances of the component and it's cloud resources, running validation against them, and then tearing down the instances. We have a test harness we use across all our projects which happens to use

go test

as the harness, but technically isn't tied in any way to Go. You can see an example here: https://github.com/pulumi/eks/blob/master/nodejs/eks/examples/examples_test.go In the case above, we only test one configuration of the EKS cluster, but we could use a similar approach to test a variety of different configurations, and could also add runtime validation that the resulting Component behaved as expected (responded to health checks, supported running app-level unit tests, etc.). I expect we will turn that test framework into a more 1st class feature in the future - with a nicer interface for defining test scenarios. There's two other test scenarios which we've talked about that might be interesting - but we haven't ourselves used either of these in anger: 1. Mocking of underlying cloud providers 2. Validating that the preview output of a component contains expected resources with expected configuration values The latter provides shallow validation that the Component does what it intends, but no validation that it actually works. The former we've been asked about, but I don't have a great motivating example of what that would mean that would be more useful than either real cloud validation or preview validation. Curious which of these approaches you had in mind for your use case?