Awsx Test Authoring

AWSX Test Authoring

Use this skill to choose and write proof for modern AWSX changes.

This skill is for test selection and assertion quality. For component shape

guidance, use $awsx-component-design. For compatibility classification, use

$awsx-breaking-change-evaluation.

Rule Index

• rules/pure-typescript-logic.md: deterministic helpers, validators,

allocators, and argument transformations.

• rules/component-construction-mocks.md: Pulumi runtime mock tests for child

resources, args passed to children, providers, region flow, and outputs.

• rules/schema-and-sdk-proof.md: schema generation, schema-tools comparison,

generated SDK diffs, and schemagen gaps.

• rules/provider-upgrade-tests.md: recorded provider upgrade preview coverage

for existing programs and state.

• rules/acceptance-tests.md: targeted examples and AWS-observed behavior.
• rules/assertion-quality.md: exact assertions, weak smoke tests, and what

counts as proof.

How To Use

• Identify the behavior that needs proof: pure logic, component construction,

schema/SDK shape, existing-state upgrade, or AWS-observed behavior.

• Read the matching rule file before adding or accepting a test.
• Prefer the cheapest test surface that proves the behavior directly.
• If the change is compatibility-sensitive, pair the test choice with

$awsx-breaking-change-evaluation.

• Report what the test proves and what it does not prove.

Stop Early

Stop before settling on a test plan if:

• the proposed test only proves that TypeScript compiles or the program runs;
• component logic is being pushed into an AWS-backed example instead of a Pulumi

runtime mock test;

• AWS-observed behavior is being asserted only through mocked child resources;
• schema changes are being judged without a generated schema or SDK diff;
• provider-upgrade evidence is being treated as refresh/update proof when it

only checks preview/no replacements;

• a broad acceptance test is proposed for a narrow deterministic change.