@aws-cdk/assert
Advanced tools
This library contains helpers for writing unit tests and integration tests for CDK libraries
Write your unit tests like this:
const stack = new Stack();
new MyConstruct(stack, 'MyConstruct', {
...
});
expect(stack).to(someExpectation(...));
Here are the expectations you can use:
Check that the synthesized stack template looks like the given template, or is a superset of it. These functions match logical IDs and all properties of a resource.
matchTemplate(template, matchStyle)
exactlyMatchTemplate(template)
beASupersetOfTemplate(template)
Example:
expect(stack).to(beASupersetOfTemplate({
Resources: {
HostedZone674DD2B7: {
Type: "AWS::Route53::HostedZone",
Properties: {
Name: "test.private.",
VPCs: [{
VPCId: { Ref: 'VPC06C5F037' },
VPCRegion: { Ref: 'AWS::Region' }
}]
}
}
}
}));
If you only care that a resource of a particular type exists (regardless of its logical identifier), and that some of its properties are set to specific values:
haveResource(type, subsetOfProperties)
Example:
expect(stack).to(haveResource('AWS::CertificateManager::Certificate', {
DomainName: 'test.example.com'
// Note: some properties omitted here
}));
Integration tests are modeled as CDK apps that are deployed by the developers. If deployment succeeds, the synthesized template is saved in a local file and "locked". During build, the test app is only synthesized and compared against the checked-in file to protect against regressions.
Create any number of files called integ.*.ts in your test directory. These
should be CDK apps containing a single stack.
Add the following to your package.json':
{
scripts: {
"test": ".... && cdk-integ-assert",
"integ": "cdk-integ"
},
...
devDependencies: {
"@aws-cdk/assert": "*",
"aws-cdk": "*"
}
}
This installs two tools into your scripts:
npm test is executed (during build), the cdk-integ-assert tool is
invoked. This tool will only synthesize the integration test stacks and
compare them to the .expected files. If the files differ (or do not exist),
the test will fail.npm run integ is executed (manually by the developer), the cdk-integ
tool is invoked. This tool will actually attempt to deploy the integration
test stacks into the default environment. If it succeeds, the .expected file
will be updated to include the latest synthesized stack.The usage of cdk-integ is:
cdk-integ [--no-clean] [filters...]
# or
npm run integ -- [--no-clean] [filters...]
--no-clean is specified, the integration test stacks will not be cleaned
up. This can be used to perform manual validation on the stacks.0.11.0 (2018-10-11)
IMPORTANT NOTE: This release includes a breaking change in the toolkit <=> app protocol. This means that in order to synthesize CDK apps that use this version, the globally installed CDK toolkit must also be updated:
$ npm i -g aws-cdk
$ cdk --version
0.11.0 (build ...)
Like always, you will also need to update your project's library versions:
Language | Update?
--------------------------- | ------------------------------------------------------------------------------------------------------------------
JavaScript/TypeScript (npm) | npx npm-check-updates -u
Java (maven) | mvn versions:use-latest-versions
.NET (NuGet) | nuget update
framework: The cdk.App constructor doesn't accept any arguments, and app.run() does not return a string anymore. All AWS CDK apps in all languages would need to be modified to adhere to the new API of the cdk.App construct.
Instead of:
const app = new App(process.argv); // ERROR
// add stacks
process.stdout.write(app.run()); // ERROR
The new usage is:
const app = new App();
// add stacks
app.run();
framework: The CDK is no longer shipped with built-in support for JSX. You can still use JSX but you will have to manually configure it.
aws-iam: PolicyDocument, PolicyStatement and all PolicyPrincipal classes moved from the @aws-cdk/cdk module and into the @aws-cdk/aws-iam module.
aws-codepipeline-api: Artifact.subartifact method of the CodePipeline API was renamed to Artifact.atPath.
constructor signature of TagManager has changed. initialTags is now passed inside a props object.
util: @aws-cdk/util is no longer available
aws-elasticloadbalancingv2: Adds classes for modeling Application and Network Load Balancers. AutoScalingGroups now implement the interface that makes constructs a load balancing target. The breaking change is that Security Group rule identifiers have been changed in order to make adding rules more reliable. No code changes are necessary but existing deployments may experience unexpected changes.
aws-cloudformation: this renames all CloudFormation Actions for CodePipeline to bring them in line with Actions defined in other service packages.
aws-codepipeline, aws-codecommit, aws-s3: change the names of the source Actions from XxxSource to XxxSourceAction. This is to align them with the other Actions, like Build. Also, CodeBuild has the concept of Sources, so it makes sense to strongly differentiate between the two.
FAQs
An assertion library for use with CDK Apps
The npm package @aws-cdk/assert receives a total of 75,847 weekly downloads. As such, @aws-cdk/assert popularity was classified as popular.
We found that @aws-cdk/assert demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 4 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Ransomware payment rates hit an all-time low in 2024 as law enforcement crackdowns, stronger defenses, and shifting policies make attacks riskier and less profitable.
Security News
require(esm) backported to Node.js 20, easing the transition to ESM-only packages and reducing complexity for developers as Node 18 nears end-of-life.
Security News
PyPI now supports iOS and Android wheels, making it easier for Python developers to distribute mobile packages.