Chaos Engineering
AWS Fault Injection Simulator (FIS) is AWS's managed chaos engineering service. It runs fault injection experiments against your AWS resources — EC2 instances, ECS tasks, RDS clusters, EKS pods, and more — without requiring agents or sidecar processes. Experiments are defined as templates in AWS, run on a schedule or
Temporal
Temporal and AWS Step Functions both orchestrate distributed workflows. But they differ significantly in how easy they are to test. This comparison covers unit testing, local development, mock support, replay testing, and CI integration. The Core Difference Temporal workflows are code. You write Go, Java, Python, or TypeScript. Tests use
AWS
AWS Step Functions orchestrate Lambda functions, ECS tasks, and other AWS services into durable workflows. Testing them requires either expensive real AWS calls or local simulation. AWS provides Step Functions Local for exactly this purpose, and moto mocks the underlying AWS services. Testing Approaches Step Functions testing has three levels:
Testing
Testing Serverless Framework applications follows the same layered approach as any Lambda testing: unit tests for business logic, integration tests using LocalStack for AWS service simulation, and end-to-end tests against a dedicated staging deployment. The Serverless Framework adds configuration complexity (serverless.yml) that can itself be tested using
Testing
LocalStack runs a local mock of AWS services in Docker. Instead of mocking the AWS SDK in your tests, point the SDK at LocalStack's endpoint and test against a real (local) S3, DynamoDB, SQS, or Lambda. This catches integration bugs that SDK mocks miss: serialization issues, IAM permission
Database Testing
DynamoDB is fast and serverless in production — but testing against live AWS DynamoDB is expensive, slow, and requires real AWS credentials. DynamoDB Local, LocalStack, and AWS SDK mocking solve this, letting you run fast, reliable tests without touching AWS. This guide covers all three approaches across Python and Node.js.
AWS
Testing Lambda functions is different from testing traditional services. Your function has no persistent process, it runs in an ephemeral container, and it's tightly coupled to AWS events and services. A function that works locally can fail in production due to IAM permissions, environment variable differences, timeout constraints,
IoT
AWS IoT Core and Azure IoT Hub are the two dominant managed IoT platforms. Both abstract away the infrastructure complexity, but they introduce new testing challenges: device provisioning flows, message routing rules, device shadows/twins, and serverless processing functions. This guide shows you how to test these integrations without sending
Testing
Event-driven architectures are notoriously difficult to test. The fundamental challenge: your service publishes an event and returns immediately. The effect of that event — a record updated in another service, a notification sent, an inventory count decremented — happens asynchronously, possibly seconds later, possibly on a different server. Traditional request/response