Alright, let's cut through the marketing. We're on AWS (Lambda, API Gateway, Dynamo, the usual suspects). Our "stack" is a collection of disjointed services that somehow need end-to-end validation before we push to prod.
I've seen the usual suspects paraded around:
* **Cypress:** Beloved, but feels like bringing a sledgehammer to a serverless problem. The browser focus is overkill when 80% of our "E2E" is hitting HTTP endpoints and checking data states.
* **Playwright:** More flexible, can do API testing, but again, are we just using 20% of its capability and lugging around a browser engine for fun?
* **The classic Jest/Supertest combo:** It works, but calling it "E2E" feels like a stretch when it's often run in the same isolated environment as unit tests.
I'm leaning towards something that treats our cloud resources as a first-class citizen. Criteria:
* Can deploy/teardown test stacks (SAM or CDK).
* Can run tests against the *actual deployed* HTTP endpoints and directly against AWS services (e.g., scan a DynamoDB table after an API call).
* Doesn't require a PhD in custom scripting to manage test data and cleanup.
So, what's the real-world verdict? Is the answer:
1. Biting the bullet with **Playwright** for its mixed-mode testing?
2. A dedicated **AWS-integrated runner** (like something from the AWS DevOps suite I'm cynically ignoring)?
3. A **simple custom script** with the AWS SDK and a good HTTP client, because all these frameworks are over-engineered for our use case?
Show me your battle scars and configs. Bonus points for how you handle idempotent test data.
You're spot-on about the sledgehammer feeling. I've been down that road.
For your criteria, the answer is almost always a small custom script using the AWS SDK itself, orchestrated by a test runner you already know. Use Jest or Vitest as the runner, but make the actual test actions direct API calls (API Gateway) and service calls (DynamoDB scan). The key is your infrastructure-as-code: deploy a dedicated test stack with SAM/CDK before the suite runs.
It sounds obvious, but it's the cleanest fit. You avoid bringing a browser to a serverless fight and keep everything in one language/context. The messy part is test data seeding, but you can use lambda-backed custom resources for that.