AWS prescriptive-guidance documentation change
Summary
Updated metadata (authors/date), modified terminology, expanded testing methodology sections, and added content about architecture/code boundary testing patterns
Security assessment
The changes primarily focus on testing methodology improvements and documentation maintenance. While there's a minor addition of 'security constructs' in architecture components list, this is not sufficient evidence of addressing security vulnerabilities. The code boundary testing patterns emphasize input validation which has security benefits, but this is presented as a testing strategy rather than explicit security documentation.
Diff
diff --git a/prescriptive-guidance/latest/serverless-application-testing/introduction.md b/prescriptive-guidance/latest/serverless-application-testing/introduction.md index c408a1fb0..7efe3f815 100644 --- a//prescriptive-guidance/latest/serverless-application-testing/introduction.md +++ b//prescriptive-guidance/latest/serverless-application-testing/introduction.md @@ -5 +5 @@ -OverviewPrerequisitesDefinitionsTargeted business outcomes +OverviewPrerequisitesDefinitionsObjectives @@ -9 +9 @@ OverviewPrerequisitesDefinitionsTargeted business outcomes - _Dan Fox, Rohan Mehta, and Rob Hill, Amazon Web Services (AWS)_ + _Amazon Web Services_ ([Contributors](./contributors.html)contributors) @@ -11 +11 @@ OverviewPrerequisitesDefinitionsTargeted business outcomes -_December 2022_ ([document history](./doc-history.html)) +_March 2026_ ([document history](./doc-history.html)) @@ -15 +15 @@ This guide discusses methodologies for testing serverless applications, describe -This guide is for developers who are looking to establish testing strategies for their serverless applications. You can use the guide as a starting point to learn about testing strategies, and then visit the [Serverless Test Samples repository](https://github.com/aws-samples/serverless-test-samples) to see examples of tests that follow the patterns and best practices described in this guide. +This guide is for developers who are looking to establish testing strategies for their serverless applications. You can use the guide as a starting point to learn about testing strategies, and then visit the [Serverless Test Samples repository](https://github.com/aws-samples/serverless-test-samples) to see examples of tests that follow the patterns and best practices described in this guide. This guide describes serverless testing methodologies, describes the challenges customers encounter when testing serverless applications, and introduces best practices for testing serverless applications. These techniques are intended to help developers iterate more quickly and release more confidently. @@ -19 +19 @@ This guide is for developers who are looking to establish testing strategies for -Automated tests are critical investments that help ensure application quality and development speed. Testing also accelerates developer feedback. As a developer, you want to be able to iterate rapidly on your application and get feedback on the quality of your code. Many developers are used to writing applications that they deploy to an environment on their desktop, either directly to their operating system or within a container-based environment. When you work in desktop or container-based environments, you typically write tests against code that is hosted entirely on your desktop. However, in serverless applications, architecture components might not be deployable to a desktop environment but might instead exist only in the cloud. A cloud-based architecture might include persistence layers, messaging systems, APIs, and other components. When you write application code that relies on these components, it might be difficult to determine the best way to design and run tests. +Automated tests are critical investments that help ensure application quality and development speed. Testing also accelerates developer feedback. As a developer, you want to be able to iterate rapidly on your application and get feedback on the quality of your code. Many developers are used to writing applications that they deploy to an environment on their desktop, either directly to their operating system or within a container-based environment. When you work in desktop or container-based environments, you typically write tests against code that is hosted entirely on your desktop. However, in serverless applications, architecture components might not be deployable to a desktop environment but might instead exist only in the cloud. A cloud-based architecture might include persistence layers, messaging systems, security constructs, APIs, and other components. When you write application code that relies on these components, it might be difficult to determine the best way to design and run tests. @@ -25 +25 @@ This guide helps you align to a testing strategy that reduces friction and confu -This guide assumes that you are familiar with the basics of automated tests, including how automated software tests are used to ensure software quality. The guide provides a high-level introduction to a serverless application testing strategy, and doesn’t require any hands-on experience writing tests. +This guide assumes that you are familiar with the basics of automated tests, including how automated software tests are used to ensure software quality. The guide provides a high-level introduction to a serverless application testing strategy, and doesn't require any hands-on experience writing tests. @@ -31 +31 @@ This guide uses the following terms: - * **Unit tests** are tests that are run against code for a single architectural component in isolation. + * _Unit tests_ are tests that are run against code for a single architectural component in isolation. @@ -33 +33 @@ This guide uses the following terms: - * **Integration tests** are run against two or more architectural components, typically in a cloud environment. + * _Integration tests_**** are run against two or more architectural components, typically in a cloud environment. @@ -35 +35 @@ This guide uses the following terms: - * **End-to-end tests** verify behaviors across an entire application. + * _End-to-end tests_ verify behaviors across entire applications or workflows. @@ -37 +37 @@ This guide uses the following terms: - * **Emulators** are applications (often provided by a third party) that are designed to mimic a cloud service without provisioning or invoking any resources. + * _Emulators_ are applications (often provided by a third party) that are designed to mimic a cloud service without provisioning or invoking any cloud resources. @@ -39 +39 @@ This guide uses the following terms: - * **Mocks** (also called _fakes_) are implementations in a testing application that replace a dependency with a simulation of that dependency. + * _Mocks_ (also called _fakes_) are implementations in a testing application that replace a dependency with a simulation of that dependency. @@ -44 +44 @@ This guide uses the following terms: -## Targeted business outcomes +## Objectives @@ -49,0 +50,4 @@ The best practices in this guide are intended to help you achieve two main objec + * Testing at architecture boundaries + + * Testing at code boundaries + @@ -57 +61 @@ The best practices in this guide are intended to help you achieve two main objec -An application’s quality depends to a large extent on the ability of developers to test a variety of scenarios to verify functionality. When you don’t implement automated tests, or, more typically, if your tests don’t cover the required scenarios adequately, the quality of your application can’t be determined or guaranteed. +An application's quality depends to a large extent on the ability of developers to test a variety of scenarios to verify functionality. When you don't implement automated tests, or, more typically, if your tests don't cover the required scenarios adequately, the quality of your application can't be determined or guaranteed. @@ -62,0 +67,85 @@ Serverless applications often consist of smaller units of work, such as AWS Lamb +#### Testing at architecture boundaries + +As serverless applications grow, they naturally spread across multiple architectural components. While this uses AWS distributed capabilities, it can make end-to-end behavior difficult to understand. + +##### Identifying natural boundaries + +When designing your architecture following serverless best practices (one function = one job, decoupling), you'll notice natural boundaries around subsystems. These boundaries represent logical separation points in your application. + +##### Boundaries as testing contracts + +These architectural boundaries are excellent candidates for testing edges. Treat each boundary as a contract and validate that it behaves according to its defined specification. Think of these boundaries as _seams_ in your application where you can insert test validation. + +##### Key benefits + +The following are key benefits of testing at architecture boundaries: + + * **Focused testing scope** – Test subsystems independently without needing to understand the entire application. + + * **Contract validation** – Ensure each boundary maintains its expected behavior as the system evolves + + * **Dual-purpose instrumentation** – These same boundaries make excellent observability hooks in production + + * **Test harness** – Allows you to test asynchronous serverless systems. It helps you test event-driven architectures by capturing and validating events as they flow through your subsystem. + + + + +#### Testing at code boundaries + +Define clear code boundaries by separating infrastructure code, such as Lambda code, from your core business logic. This separation creates distinct testing scopes that simplify your test strategy. + +##### The boundary pattern + +Establish two clear code boundaries in your Lambda functions: + + * **Outer boundary (Lambda handler)** – A slim adapter layer that handles concerns specific to AWS Lambda + + * **Inner boundary (business logic)** – Pure business logic methods independent of Lambda runtime + + + + +##### Handler as adapter (outer scope) + +Your Lambda function handler should be a thin layer that: + + * Extracts data from the incoming `event` and `context` objects + + * Validates the extracted data + + * Passes only relevant details to business logic methods + + * Returns results in the expected format for Lambda + + + + +##### Business logic (inner scope) + +Your core business logic should: + + * Operate independently of details specific to Lambda + + * Accept simple, validated inputs + + * Return predictable outputs + + * Require minimal dependencies for initialization + + + + +##### Testing benefits by scope + + * **Inner boundary tests** – Comprehensive unit tests around business logic without Lambda complexity or environment setup + + * **Outer boundary tests** – Focused integration tests validating the adapter layer's event handling and data extraction + + * **Minimal test overhead** – No complex environments or extensive dependencies needed for the majority of your tests + + + + +This boundary-based approach allows you to test most of your code as pure functions while keeping Lambda tests minimal and targeted. + @@ -65 +154 @@ Serverless applications often consist of smaller units of work, such as AWS Lamb -Software bugs and configuration problems have the least effect on costs and schedules when you’re able to catch these issues during an iterative development cycle. When these issues remain undetected by a developer, identifying problems requires additional effort from more people. +You can minimize the effect of software bugs and configuration problems on costs and schedules by catching these issues during an iterative development cycle. When a developer fails to detect these issues, more people must invest additional effort to identify the problems. @@ -67 +156 @@ Software bugs and configuration problems have the least effect on costs and sche -A serverless architecture might include managed services that provide critical application functionality through API calls. For this reason, your development cycle should include tests that accurately demonstrate the proper functionality when interacting with these services. If these tests are not in place, you might encounter issues that arise from the differences between your environment and the deployed environment. As a result, you might spend even more time attempting to reproduce and verify a fix, because the iteration now requires checking the changes against an environment that’s different from your preferred setup. +A serverless architecture might include managed services that provide critical application functionality through API calls. For this reason, your development cycle should include tests that validate both the _happy path_ (where interactions with these services behave as expected) and the _sad path_ (where calls fail, return unexpected responses, or behave differently across environments). Without these tests in place, you may encounter issues that stem from differences between your local environment and the deployed environment. When that happens, you must spend additional time attempting to reproduce and verify a fix, because each iteration now requires validating changes against an environment that differs from your preferred setup. @@ -77 +166 @@ To use the Amazon Web Services Documentation, Javascript must be enabled. Please -Testing techniques +Testing techniques for serverless applications