Contract tests for resource types
As part of testing your resource, the CloudFormation CLI performs a suite of tests, each written to test a requirement contained in the resource type handler contract. Each handler invocation is expected to follow the general requirements for that handler listed in the contract. This topic lists tests that explicitly test some more specific requirements.
When you run the contract tests with the --v2 flag, the CloudFormation CLI
runs the test suite described in
Contract tests performed with the --v2 flag.
Tests run with --v2 additionally validate your resource schema, your test
input files, and the live state of provisioned resources. When you register a resource
type, it must pass the --v2 tests. This requirement applies to all newly
registered resource types.
create handler tests
The CloudFormation CLI performs the following contract tests for
create handlers.
| Test | Description |
|---|---|
|
|
Creates a resource, waits for the resource creation to
complete, and then creates the resource again with the
expectation that the second create operation will fail with the
|
|
|
Creates a resource, waits for the resource creation to
complete, and then reads the created resource to ensure that the
input to the |
|
|
Creates a resource, waits for the resource creation to complete, and then deletes the created resource. It also checks if the create input is equal to the create output (which is then used for delete input), with the exception of readOnly and writeOnly properties. |
|
|
Creates a resource, waits for the resource creation to complete, and then lists out the resources with the expectation that the created resource exists in the returned list. |
update handler tests
The CloudFormation CLI performs the following contract tests for
update handlers.
| Test | Description |
|---|---|
|
|
Creates a resource, updates the resource, and then reads the resource to check that the update was made by comparing the read output with the update input. The comparison excludes read-only and write-only properties because they can't be included in the update input and read output, respectively. |
|
|
Creates a resource, updates the resource, and then lists the resource to check that the updated resource exists in the returned list. |
|
|
Updates a resource without creating it first. The test expects
the update operation to fail with the |
delete handler tests
The CloudFormation CLI performs the following contract tests for
delete handlers.
| Test | Description |
|---|---|
|
|
Creates a resource, deletes the resource, and then creates the resource again with the expectation that the deletion was successful and a new resource can be created. The CloudFormation CLI performs this contract test for resources with create-only primary identifiers. |
|
|
Creates a resource, deletes the resource, and then updates the
resource with the expectation that the update operation will
fail with the |
|
|
Creates a resource, deletes the resource, and then reads the
resource with the expectation that the read operation will fail
with the |
|
|
Creates a resource, deletes the resource, and then lists the resource with the expectation that the returned list doesn't contain the deleted resource. |
|
|
Creates a resource, deletes the resource, and then deletes the
resource again with the expectation that the second delete
operation will fail with the |
Contract tests performed with the --v2 flag
When you run cfn test --v2, the CloudFormation CLI automatically
selects the applicable tests based on the handlers and properties declared in your
resource type schema. In addition to handler tests, the --v2 suite
validates your resource schema and your test input files. It also verifies the live
state of resources after mutating operations by reading them back.
Schema validation tests
The following table describes the schema validation tests that the --v2
suite performs.
| Test | Description |
|---|---|
|
Schema linter checks |
Validates the resource schema against the resource schema validation rules. Each failed check reports the rule, message, and schema path. |
|
Schema backward-compatibility checks |
Compares the schema against your previously registered schema version and fails on breaking changes, such as removed properties, tightened constraints, or a changed primary identifier. |
create handler tests
The following table describes the create handler tests that the
--v2 suite performs.
| Test | Description |
|---|---|
|
|
Creates a resource and expects |
|
|
While the first resource exists, invokes the
|
|
|
If the second create returns |
|
|
Reads the original resource after the second create (and
after any rollback delete) and expects |
|
|
After a successful create, a subsequent |
|
|
Reads the created resource, removes read-only properties from the output, and uses the result as the desired state for a new create. The create must succeed, proving that read output is usable as a template. |
read output tests
These assertions are applied to read responses throughout the
suite.
| Test | Description |
|---|---|
|
|
A |
|
|
Every property in |
|
|
Properties in |
|
|
The |
|
|
The union of all successful |
update handler tests
The following table describes the update handler tests that the
--v2 suite performs.
| Test | Description |
|---|---|
|
|
Creates a resource, applies the update input, and expects
the update to return |
|
|
After a successful update, a |
|
|
The primary identifier returned by the update must equal the identifier returned by the create. |
|
|
A |
|
|
After a successful update, a |
delete handler tests
The following table describes the delete handler tests that the
--v2 suite performs.
| Test | Description |
|---|---|
|
|
Creates a resource and expects a subsequent delete to
return |
|
|
After a successful delete, a |
|
|
After a successful delete, an |
|
|
After a successful delete, a second |
|
|
After a successful delete, the deleted resource must not
appear in |
|
|
After a successful delete, creating the resource again must
not fail with |
list handler tests
The following table describes the list handler tests that the
--v2 suite performs.
| Test | Description |
|---|---|
|
|
After a successful create, a |
|
|
Every primary identifier returned by |
Test input validation
The following table describes the test input validation checks that the
--v2 suite performs.
| Test | Description |
|---|---|
|
|
Test input files must not contain hardcoded Region names;
use the |
|
|
Test input files must not contain hardcoded account IDs;
use the |
|
|
Test input files must not contain hardcoded partition
names; use the |
Property coverage
Your create and update inputs together must exercise the properties declared in your schema. Missing or invalid coverage is reported per property path.
Note
The {{region}}, {{account}}, and
{{partition}} template variables apply to input files used
with --v2. With the default cfn test command,
{{ }} expressions in input and override files refer to
CloudFormation stack exports in your account.