No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Usually, the easiest is to omit extra interfaces like Pulumi config from your unit testing. If you limit using Pulumi config to your "main" file, and use ComponentResources as your testable units, then you don't need to fake out things like Pulumi config, environment variables, vaults etc.

You can test all those things at system / integration testing time, with fewer (or no) fakes.

When you're unit testing, pass the test inputs into your objects under test via their args parameters. Omit getting anything from the config.

Adding an Environment Variable has worked... I would be better if `Pulumi.Config` implemented an interface though, and I could use DI to inject it.

That means that your internal code is dependent on an interface rather than provided values. DI could be injecting the values, rather that the interface to access those values.

Essentially, you've got two dependency-resolution systems: your preferred DI provider, and Pulumi config. One would be easier to manage.

I get the idea there, and probably a better option is to inject a pre-parsed config object into the object.  Need to have a think why I don't like that, but there's something niggling that it doesn't test the right things.

Essentially it's changing the DI from transitive (where your object is dependent on a thing (DI) and that thing is dependent on all the values that your object should be dependent on) to direct (your object is dependent on value; end of story).