test: add CFN synthesis tests covering 24 plugin scenarios#704
Conversation
Adds a second-tier test suite that exercises the plugin against real serverless.yml configurations and asserts on the generated CloudFormation template, complementing the existing 287 unit tests. Coverage (24 fixtures, 68 assertions): Auth (6): basic-api-key, cognito-userpools, iam-auth, oidc-auth, lambda-authorizer, multi-auth Resolvers (3): lambda-resolvers-js (JS code + esbuild bundling), lambda-resolvers-vtl (VTL templates), pipeline-resolvers Data sources (6): datasource-http (incl. IAM-signed variant), datasource-none, datasource-eventbridge, datasource-opensearch, datasource-rds, plus DynamoDB and Lambda covered transitively Advanced features (9): caching (API + per-resolver), waf (rules, associations), logging-xray, custom-domain (CloudFormation-managed), introspection-disabled (with queryDepth/resolverCount limits), substitutions, environment-variables, api-keys-multiple, tags, visibility-private, schema-multiple-files Infrastructure: - e2e/helpers/synthesize.ts — runs sls package via subprocess, returns parsed CFN template, cleans up temp dirs - e2e/helpers/assertions.ts — readable assertion helpers (expectAuthenticationType, expectDataSourceOfType, etc.) - jest.e2e.config.ts + jest.e2e.setup.ts — separate config; globalSetup creates the examples/node_modules/serverless-appsync-plugin symlink so example projects resolve the plugin from the current source tree - Each example is a copy-paste-ready user project doubling as a test fixture, eliminating the docs/tests duplication problem - examples/README.md indexes all 24 examples for users - e2e/README.md explains the testing strategy for contributors CI: new 'e2e' job in .github/workflows/ci.yml runs after the unit-test matrix on every PR and push to master/alpha. Single Node version (22) since CFN output doesn't vary by Node version; full suite takes ~70s. Real plugin behaviors caught while building the fixtures (used to refine the examples): - API_KEY auth silently produces zero API keys if 'apiKeys:' is omitted - HTTP data sources with AWS_IAM authorization require explicit iamRoleStatements - OpenSearch data source can't auto-derive ARN from Fn::GetAtt; needs 'domain:' field naming the CloudFormation resource Verified: npm run test:all passes (287 unit + 68 e2e), npm run lint clean.
| needs: tests | ||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v5 |
There was a problem hiding this comment.
@sid88in let's switch to the latest v6 version
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v5 | ||
| - uses: actions/setup-node@v5 |
There was a problem hiding this comment.
@sid88in this one, also could be switched to v6
| uses: actions/checkout@v5 | ||
| - uses: actions/setup-node@v5 | ||
| with: | ||
| node-version: 22 |
There was a problem hiding this comment.
@sid88in the plugin supports 20, 22, 24, and 26 versions, just curious why 22?
There was a problem hiding this comment.
CFN output is identical across Node versions. Running 4 Node versions for the synthesis tests would be 4x the CI minutes for zero added signal. The unit-test matrix already verifies the plugin works across Node 20/22/24/26 — those tests exercise the actual plugin logic. The e2e job tests the output of that logic, which doesn't change based on Node.
That said, 22 is somewhat arbitrary — could have been any of the four. For now I will keep it 22
| | 'API_KEY' | ||
| | 'AWS_IAM' | ||
| | 'AMAZON_COGNITO_USER_POOLS' | ||
| | 'OPENID_CONNECT' | ||
| | 'AWS_LAMBDA', |
|
|
||
| provider: | ||
| name: aws | ||
| runtime: nodejs20.x |
There was a problem hiding this comment.
@sid88in nodejs20 is not supported by AWS, only 22 and 24
There was a problem hiding this comment.
good catch node 20x is EOL April 30, moved to 22
- Bump actions/checkout and actions/setup-node to v6 (latest stable) in both the tests and e2e jobs of .github/workflows/ci.yml - Bump all example runtimes from nodejs20.x to nodejs22.x. Node 20 reached EOL on April 30 2026; Lambda console removed it then and function updates will be blocked from Sep 30 2026. Examples should reflect the current recommended runtime so users copying them get a supported runtime by default. - Export AuthenticationType union from src/types/common.ts (derived from the existing Auth discriminated union via Auth['type']) and use it in e2e/helpers/assertions.ts instead of duplicating the literal string union. Keeps the e2e helper and the source of truth in sync automatically if a new auth type is ever added. Re: 'why Node 22 for the e2e job and not the full 20/22/24/26 matrix?' The CFN output produced by serverless package is identical across Node versions (no Node-specific code paths in synthesis). The existing unit-test matrix already verifies plugin logic across all four Node versions; running the synthesis tests across the same matrix would 4x CI minutes for zero added signal. 22 specifically matches what the Release workflow uses, keeping CI consistent.
|
@AlexHladin please review the CR again. addressed comments - pls verify |
test: add CFN synthesis tests covering 24 plugin scenarios
What
Adds a second-tier test suite that exercises the plugin against real
serverless.ymlconfigurations and asserts on the generatedCloudFormation, complementing the existing 287 unit tests. Includes 24
runnable example projects under
examples/that double as user-facingdocumentation.
Why
Unit tests catch logic and validation bugs but can't tell you whether
the plugin actually produces working CloudFormation across the matrix
of features users combine in practice. This adds that layer without
requiring AWS credentials or real deployments —
sls packagedoes thesynthesis locally and we assert on the template.
Side benefit: the project had no
examples/folder. Users had to readthe test fixtures or piece together docs to learn how to configure a
feature. These examples are copy-paste-ready and guaranteed to stay
current with the plugin's actual behavior — if they break, CI fails.
Coverage
24 fixtures, 68 assertions:
Auth (6):
basic-api-key,cognito-userpools,iam-auth,oidc-auth,lambda-authorizer,multi-authResolvers (3):
lambda-resolvers-js(JS code with@aws-appsync/utils),lambda-resolvers-vtl(VTL templates),pipeline-resolversData sources (6):
datasource-http(with both unauthenticated andIAM-signed variants),
datasource-none,datasource-eventbridge,datasource-opensearch,datasource-rds, plus DynamoDB and Lambdacovered transitively through other fixtures
Advanced features (9):
caching(API + per-resolver),waf(rules + association),logging-xray,custom-domain(CloudFormation-managed),
introspection-disabled(with
queryDepthLimitandresolverCountLimit),substitutions,environment-variables,api-keys-multiple,tags,visibility-private,schema-multiple-filesInfrastructure
e2e/helpers/synthesize.ts— runssls packagevia a child process,returns the parsed CFN template, cleans up temp dirs
e2e/helpers/assertions.ts— readable assertion helpers(
expectAuthenticationType,expectDataSourceOfType,expectResourceWithProperties, etc.)jest.e2e.config.ts+jest.e2e.setup.ts— separate Jest config(so unit-test feedback stays fast);
globalSetupcreates theexamples/node_modules/serverless-appsync-pluginsymlink so exampleprojects resolve the plugin from the current source tree, without
needing a per-example
npm installexamples/README.mdindexes all 24 examples for users browsing the repoe2e/README.mdexplains the testing strategy for contributorsCI
New
e2ejob in.github/workflows/ci.ymlruns after the unit-testmatrix on every PR and push to
masteroralpha. Single Node version(22) since CFN output doesn't vary by Node version — runs in ~70 seconds.
Real plugin behaviors caught while building the fixtures
These are the kind of "silent gotcha" issues the suite is meant to
surface — found and used to refine the examples themselves:
API_KEYauth silently produces zero API keys ifapiKeys:arrayisn't specified
AWS_IAMauthorization require explicitiamRoleStatementsFn::GetAtt— they need an explicit
domain:field naming the CloudFormationresource
How to run locally
Verified
npm run test— 287 unit tests passnpm run test:e2e— 68 synthesis assertions across 25 suites passnpm run lint— clean (0 errors, 0 warnings)npm run build— cleanWhat's not in this PR (intentionally)
needs a dedicated AWS test account and OIDC setup
merged-apiexample — the plugin doesn't supportMERGEDAPItype yet; that's a roadmap item, not a missed test
Follow-ups for after merge
scheduled cadence
API once supported, MERGED APIs once supported)
examples/folder