pulumi/pkg/engine/lifecycletest
Will Jones 85e39e09f6
Add the ability to fuzz parents and aliases (#17654)
In #17623 and the PRs that followed it, we added fuzz testing
capabilities to the engine's lifecycle test suite, with a view to
randomly generating test cases in the hopes of proactively finding
snapshot integrity bugs in our code. This commit extends the fuzzer so
that it randomly parents, re-parents, and aliases reparented resources,
covering the various parent/child relationships that these actions lead
to and which can result in snapshot integrity issues if handled
improperly. In particular, we can now fuzz the following:

* Randomly parenting a resource to another resource in an initial
snapshot.
* Randomly updating a resource in a program to either add, remove, or
change an existing parent.
* Randomly aliasing a resource whose parent (and consequently URN) has
been changed by a program to point back to the URN it had originally.

Part of #17213
2024-11-01 10:32:56 +00:00
..
framework Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
fuzzing Add the ability to fuzz parents and aliases (#17654) 2024-11-01 10:32:56 +00:00
testdata Spot skipped-create dependencies even when inputs don't change (#17633) 2024-10-30 16:17:30 +00:00
README.md Support generating random fixtures in lifecycle tests (#17627) 2024-10-31 15:16:38 +00:00
alias_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
analyzer_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
continue_on_error_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
delete_before_replace_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
golang_sdk_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
import_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
loader_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
parameterized_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
pending_delete_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
pending_replace_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
provider_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
pulumi_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
refresh_legacy_diff_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
refresh_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
resource_reference_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
retain_on_delete_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
source_query_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
step_generator_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
target_test.go Spot skipped-create dependencies even when inputs don't change (#17633) 2024-10-30 16:17:30 +00:00
transformation_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00
update_plan_test.go Factor out the lifecycle testing framework (#17584) 2024-10-28 11:58:59 +00:00

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