mirror of https://github.com/pulumi/pulumi.git
6e04a284a5
Fuzzed lifecycle tests work slightly differently to their handwritten counterparts. A handwritten test will typically "start from nothing". An initial snapshot is built from an empty state and starting program, before subsequent operations are executed on this state to test behaviour. In constrast, fuzzed tests create arbitrary starting snapshots "out of thin air", before running an operation to see if a bug can be triggered. Ideally, any starting state conjured by a fuzz test is actually reproducible from an empty state and some combination of operations, but it may be that this is not the case, or that the number of operations required to reach the state is very high. In such cases, it is handy to have the exact code the fuzz test used to hand when reproducing and isolating behaviour. To this end, this commit extends the `reprogen` functionality of the suite to generate this code as well as the existing "handwritten" approximation. This should also aid in minimising failing test cases quickly when bugs are found. |
||
|---|---|---|
| .. | ||
| framework | ||
| fuzzing | ||
| testdata | ||
| README.md | ||
| alias_test.go | ||
| analyzer_test.go | ||
| continue_on_error_test.go | ||
| delete_before_replace_test.go | ||
| fuzz_test.go | ||
| golang_sdk_test.go | ||
| import_test.go | ||
| loader_test.go | ||
| parameterized_test.go | ||
| pending_delete_test.go | ||
| pending_replace_test.go | ||
| provider_test.go | ||
| pulumi_test.go | ||
| refresh_legacy_diff_test.go | ||
| refresh_test.go | ||
| resource_reference_test.go | ||
| retain_on_delete_test.go | ||
| source_query_test.go | ||
| step_generator_test.go | ||
| target_test.go | ||
| transformation_test.go | ||
| update_plan_test.go | ||
README.md
(lifecycle-tests)=
Lifecycle tests
Lifecycle tests exercise the Pulumi engine and serve as a specification for the behaviours and interactions of the various features that define the lifecycle of a Pulumi program. This includes, but is not limited to:
- The operation(s) being executed (
up,preview, etc.) and the options passed to that operation (--target,--target-dependents, etc.). - The programs being executed -- their resources, invocations, and the various
options that might be associated with them (
parent,retainOnDelete, etc.). - The state of the program before and after operations are executed.
How and when to use