You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+25-5Lines changed: 25 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@
3
3
Library for testing Pulumi providers by running Pulumi programs.
4
4
5
5
> [!NOTE]
6
-
> The libraries in this repo are used internally by the Pulumi providers team, and are still evolving; you should expect incomplete documentation and breaking changes. If you do choose to use this library we strongly recommend starting with [providertest/pulumitest](https://github.com/pulumi/providertest/tree/main/pulumitest) which is our latest approach. The ProviderTest abstraction is deprecated and will removed in a future release.
6
+
> The libraries in this repo are used internally by the Pulumi providers team, and are still evolving; you should expect incomplete documentation and breaking changes. If you do choose to use this library we strongly recommend starting with [providertest/pulumitest](https://github.com/pulumi/providertest/tree/main/pulumitest) which is our latest approach. The ProviderTest abstraction is deprecated and will be removed in a future release.
7
7
8
8
The library is composed of several modules. The most important of these is the [`pulumitest`](./pulumitest/) module. This is a library designed for testing any Pulumi program within a Go test. It extends the Go [Automation API](https://www.pulumi.com/automation/) with defaults appropriate for local testing such as using temporary directories for state.
Refer to [the full documentation](./pulumitest/README.md) for a complete walkthrough of the features.
27
27
28
+
## Attaching In-Process Providers
29
+
30
+
If your provider implementation is available in the context of your test, the provider can be started in a background goroutine and used within the test using the `opttest.AttachProviderServer`. This avoids needing to build a provider binary before running the test, and allows stepping through from the test to the provider implementation when attaching a debugger.
31
+
32
+
For bridged providers using the standard repository layout, this can be configured as such:
For native providers this function just returns your implementation of [the `pulumirpc.ResourceProviderServer` interface](https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v3/proto/go#ResourceProviderServer).
47
+
28
48
## Upgrade Testing
29
49
30
-
We perform "upgrade testing" on providers to indicate when there's a change in a new version of a provider which might cause resources to be re-created during an upgrade from a previous version.
50
+
We perform "upgrade testing" on providers to fail when a resource might be re-created when updating to a new version of the provider.
31
51
32
52
In the root `providertest` module there is a function called `PreviewProviderUpgrade(..)`. This shows the result of a preview when upgrading from a **baseline** version of a provider to a new version of the provider. On first run it records the *baseline* state after running the program with the *baseline* version of the provider and writes it into a `testdata` directory. On subsequent runs, it restores the state from the recorded *baseline* before performing a preview operation with the new version.
33
53
@@ -36,7 +56,7 @@ Here's an example of how to write an upgrade test:
0 commit comments