Minor update to 'Testing AWS CDK applications' page

Author: evzzk

v2/best-practices.md

@@ -102,7 +102,7 @@ In general, environment variable lookups should be limited to the top level of a
 
 ### Unit test your infrastructure<a name="best-practices-constructs-test"></a>
 
-To consistently run a full suite of unit tests at build time in all environments, avoid network lookups during synthesis and model all your production stages in code\. \(These best practices are covered later\.\) If any single commit always results in the same generated template, you can trust the unit tests that you write to confirm that the generated templates look the way you expect\. For more information, see [Testing constructs](testing.md)\.
+To consistently run a full suite of unit tests at build time in all environments, avoid network lookups during synthesis and model all your production stages in code\. \(These best practices are covered later\.\) If any single commit always results in the same generated template, you can trust the unit tests that you write to confirm that the generated templates look the way you expect\. For more information, see [Test AWS CDK applications](testing.md)\.
 
 ### Don't change the logical ID of stateful resources<a name="best-practices-constructs-logicalid"></a>
 

v2/cli.md

@@ -326,7 +326,7 @@ The CDK CLI actually runs your app and synthesizes fresh templates before most o
 
 See `cdk synth --help` for all available options\. A few of the most frequently used options are covered in the following section\.
 
-### Specify context values<a name="w92aac61c33c11"></a>
+### Specify context values<a name="w92aac65c33c11"></a>
 
 Use the `--context` or `-c` option to pass [runtime context](context.md) values to your CDK app\.
 
@@ -345,15 +345,15 @@ When deploying multiple stacks, the specified context values are normally passed
 cdk synth --context Stack1:key=value Stack2:key=value Stack1 Stack2
 ```
 
-### Specify display format<a name="w92aac61c33c13"></a>
+### Specify display format<a name="w92aac65c33c13"></a>
 
 By default, the synthesized template is displayed in YAML format\. Add the `--json` flag to display it in JSON format instead\.
 
 ```
 cdk synth --json MyStack
 ```
 
-### Specify the output directory<a name="w92aac61c33c15"></a>
+### Specify the output directory<a name="w92aac65c33c15"></a>
 
 Add the `--output` \(`-o`\) option to write the synthesized templates to a directory other than `cdk.out`\.
 
@@ -429,7 +429,7 @@ Git\-style wildcards, both `*` and `**`, can be used in the `"watch"` and `"buil
 **Important**  
 Watch mode is not recommended for production deployments\.
 
-### Specify AWS CloudFormation parameters<a name="w92aac61c35c19"></a>
+### Specify AWS CloudFormation parameters<a name="w92aac65c35c19"></a>
 
 The CDK CLI supports specifying AWS CloudFormation [parameters](parameters.md) at deployment\. You may provide these on the command line following the `--parameters` flag\.
 
@@ -451,7 +451,7 @@ cdk deploy MyStack YourStack --parameters MyStack:uploadBucketName=UploadBucket
 
 By default, the AWS CDK retains values of parameters from previous deployments and uses them in later deployments if they are not specified explicitly\. Use the `--no-previous-parameters` flag to require all parameters to be specified\.
 
-### Specify outputs file<a name="w92aac61c35c21"></a>
+### Specify outputs file<a name="w92aac65c35c21"></a>
 
 If your stack declares AWS CloudFormation outputs, these are normally displayed on the screen at the conclusion of deployment\. To write them to a file in JSON format, use the `--outputs-file` flag\.
 

v2/index.md

@@ -66,6 +66,7 @@ sponsored by Amazon.
 + [Deploy AWS CDK applications](deploy.md)
    + [AWS CDK policy validation at synthesis time](policy-validation-synthesis.md)
    + [Continuous integration and delivery (CI/CD) using CDK Pipelines](cdk_pipeline.md)
++ [Test AWS CDK applications](testing.md)
 + [AWS CDK CLI reference](cli.md)
 + [AWS CDK CLI command reference](ref-cli-cmd.md)
    + [cdk acknowledge](ref-cli-cmd-ack.md)
@@ -91,7 +92,6 @@ sponsored by Amazon.
    + [Example: Create a CDK app with multiple stacks](stack_how_to_create_multiple_stacks.md)
    + [Example: Create an AWS Fargate service using the AWS CDK](ecs_example.md)
 + [Use other tools with the AWS CDK](tools.md)
-+ [Testing constructs](testing.md)
 + [Security for the AWS Cloud Development Kit (AWS CDK)](security.md)
    + [Identity and access management for the AWS Cloud Development Kit (AWS CDK)](security-iam.md)
    + [Compliance validation for the AWS Cloud Development Kit (AWS CDK)](compliance-validation.md)

v2/serverless_example.md

@@ -1494,7 +1494,7 @@ CdkHelloWorldStack: destroying... [1/1]
 
 ## Troubleshooting<a name="serverless-example-troubleshooting"></a>
 
-### Error: \{“message”: “Internal server error”\}%<a name="w92aac73c11c55b5"></a>
+### Error: \{“message”: “Internal server error”\}%<a name="w92aac77c11c55b5"></a>
 
 When invoking the deployed Lambda function, you receive this error\. This error could occur for multiple reasons\.
 

v2/testing.md

@@ -1,4 +1,4 @@
-# Testing constructs<a name="testing"></a>
+# Test AWS CDK applications<a name="testing"></a>
 
 With the AWS CDK, your infrastructure can be as testable as any other code you write\. The standard approach to testing AWS CDK apps uses the AWS CDK's [assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) module and popular test frameworks like [Jest](https://jestjs.io/) for TypeScript and JavaScript or [Pytest](https://docs.pytest.org/en/6.2.x/) for Python\.