Hands-on Serverless Testing
From the previous sections of this chapter, you should have started to form a mental model of how to approach testing a serverless application. Now it’s time to look at applying this model to an example architecture.
Before testing any application, it is important to understand exactly what you are testing. As you’ve seen in this chapter, serverless applications will most likely be sub‐ stantially different from other types of applications you and your team have tested in the past, such as monolithic server-based backends or client-centric web applications. The two attributes of serverless that most impact testing are the extensive use of managed services and the event-driven interaction between these services as data flows through the system.
Event-Driven Testing
If you look beyond the purpose of your software product and the myriad AWS services available to you and instead scrutinize the patterns and actors in a serverless application, you will notice a group of recurring elements (see Figure 7-3). When dissected, an event-driven serverless application consists purely of business logic,managed services, and the integration points between them. Effective testing relies on a clear delineation of the responsibilities between you and AWS. You are responsible for testing the business logic and integration configuration that you own. Take care not to test the managed services, events, integrations, and APIs that AWS owns.
Figure 7-3. What to test and what not to test in a serverless application
Let’s take a closer look at where you should focus your testing efforts.
Business logic, integration points, and data contracts
These are the three fundamental building blocks to event-driven, serverless applica‐ tions that are crucial to understand in order to test such applications:
Business logic
The code that you write and deploy to AWS for execution is the business logic of your application; the parts of your software that encode the functional require‐ ments and business rules of the application’s domain. The business logic is the internal mechanics of your system that you own. You are responsible for author‐ ing, maintaining, deploying, and operating this code. You are also responsible for testing this code.
Integration points
The distributed components of a serverless application operate in isolation and communicate their independent activity to each other through asynchronous events or synchronous requests. Architecturally speaking, these events and requests reside in a zone between the source and target that can be referred to as an integration point. The integration point between two components rep‐ resents the method of communication and the format and structure of the messages passed between them. The integration points in your system will almost exclusively be owned and operated by AWS, but you will be responsible for configuring these integration points and defining the rules that govern the communication.
Data contracts
A data contract is an encoded ruleset to facilitate communication between logi‐ cally decoupled services. These contracts are applied between two components in your system, at their point of integration, and enforce the target’s expectations of a source. As well as facilitating verifiable communication at runtime, data contracts are crucial to enabling a scalable and efficient test strategy.
Figure 7-4 shows how these elements map to a simple serverless architecture: the EventBridge managed service is used alongside business logic in a Lambda function, and you can see two integration points and the types of data contracts that can exist between the components. The following sections introduce the types of tests that can be used to test this architecture.
Figure 7-4. Reference architecture of a simple event-driven flow showing a common serverless pattern