-
Notifications
You must be signed in to change notification settings - Fork 16
[SVLS-8054] add integration testing #946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
5ad68e5
a85263a
5eaffd1
db5d0ac
5bc76bc
14d281c
4283e48
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,2 @@ | ||
| /bottlecap/target/ | ||
| bottlecap/target/ | ||
| integration-tests/ |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| # CDK | ||
| *.js | ||
| !jest.config.js | ||
| !lambda/**/*.js | ||
| *.d.ts | ||
| node_modules | ||
| cdk.out | ||
| .cdk.staging | ||
|
|
||
| # Compiled output | ||
| dist/ | ||
| *.tsbuildinfo | ||
|
|
||
| # Logs | ||
| *.log | ||
| npm-debug.log* | ||
|
|
||
| # Testing | ||
| coverage/ | ||
| .nyc_output/ | ||
| test-results/ | ||
|
|
||
| # Environment | ||
| .env | ||
| .env.local | ||
|
|
||
| # IDE | ||
| .vscode/ | ||
| .idea/ | ||
| *.swp | ||
| *.swo | ||
| *~ | ||
|
|
||
| # OS | ||
| .DS_Store | ||
| Thumbs.db | ||
|
|
||
| # Lambda artifacts | ||
| response.json | ||
| lambda-bundle.zip |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
| # Datadog Lambda Extension Integration Tests | ||
|
|
||
| This directory contains integration tests for the Datadog Lambda Extension. | ||
|
|
||
| The general flow is: | ||
| 1. Deploy test setup using CDK. | ||
| 2. Invoke lambda functions. | ||
| 3. Wait for data to propagate to Datadog. | ||
| 4. Call Datadog to get telemetry data and check the data based on test requirements. | ||
|
|
||
| For simplicity, integraiton tests are setup to only test against ARM runtimes. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i'd think that if this is intended to test the extension, then making sure that it is built correctly for arm vs. amd runtimes becomes important. or have we never seen architecture-dependent differences in our extension builds?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think just having arm for now is a sufficient starting point and we can expand on this later as needed/as we have time. |
||
|
|
||
| ## Guidelines | ||
|
|
||
| ### Naming | ||
| * An `identifier` is used to differentiate the different stacks. For local development, the identifier is automatically set using the command `whoami` and parses the user's first name. For gitlab pipelines, the identifier is the git commit short sha. | ||
| * Stacks should be named `integ-<identifier>-<stack name>` | ||
| * Lambda functions should be named `<stack-id>-<function name>` | ||
|
|
||
| ### Stacks | ||
| * Stacks automatically get destroyed at the end of the gitlab integration tests step. Stack should be setup to not retain resources. A helper function `createLogGroup` exists with `removalPolicy: cdk.RemovalPolicy.DESTROY`. | ||
|
|
||
|
|
||
| ## Local Development | ||
|
|
||
| ### Prerequisites Set env variables | ||
| **Datadog API Keys**: Set environment variables | ||
| ```bash | ||
| export DD_API_KEY="your-datadog-api-key" | ||
| export DD_APP_KEY="your-datadog-app-key" | ||
| export DATADOG_API_SECRET_ARN="arn:aws:secretsmanager:us-east-1:ACCOUNT_ID:secret:YOUR_SECRET" | ||
| ``` | ||
|
|
||
| ### 1. Build and Deploy Extension Layer | ||
|
|
||
| First, publish your extension layer. | ||
|
|
||
| ```bash | ||
| ./scripts/local_publish.sh | ||
| ``` | ||
|
|
||
| This will create and publish `Datadog-Extension-ARM-<your name>`. | ||
|
|
||
| ### 2. Deploy Test Stacks | ||
|
|
||
| Deploy the CDK stacks that create Lambda functions for testing. | ||
|
|
||
| ```bash | ||
| ./scripts/local_deploy.sh <stack name> | ||
| ``` | ||
|
|
||
| This will create `integ-<your name>-<stack name>`. The stacks will use the lambda extension created in the previous step. | ||
|
|
||
| ### 3. Run Integration Tests | ||
|
|
||
| Run Jest tests that invoke Lambda functions and verify Datadog telemetry: | ||
|
|
||
| ```bash | ||
| # All tests | ||
| npm test | ||
|
|
||
| # Single test | ||
| npm test -- <my test file> | ||
| ``` | ||
|
|
||
|
|
||
|
|
||
| **Note**: Tests wait for a few minutes after Lambda invocation to allow telemetry to appear in Datadog. | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| #!/usr/bin/env node | ||
| import 'source-map-support/register'; | ||
| import * as cdk from 'aws-cdk-lib'; | ||
| import { BaseNodeStack } from '../lib/stacks/base-node-stack'; | ||
| import { BasePythonStack } from '../lib/stacks/base-python-stack'; | ||
| import { getIdentifier } from '../tests/utils/config'; | ||
|
|
||
| const app = new cdk.App(); | ||
|
|
||
| const env = { | ||
| account: process.env.CDK_DEFAULT_ACCOUNT || process.env.AWS_ACCOUNT_ID, | ||
| region: process.env.CDK_DEFAULT_REGION || process.env.AWS_REGION || 'us-east-1', | ||
| }; | ||
|
|
||
| const identifier = getIdentifier(); | ||
|
|
||
| new BaseNodeStack(app, `integ-${identifier}-base-node`, { | ||
| env, | ||
| }); | ||
|
|
||
| new BasePythonStack(app, `integ-${identifier}-base-python`, { | ||
| env, | ||
| }); | ||
|
|
||
| app.synth(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be worth adding some notes here about the sorts of tests we should be including in this suite (vs the e2e test suite.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is too much to note - This is for the extension, the other e2e test suite is what the apm serverless team uses. There is overlap, but will let engineers use their judgement. Can re-evaluate this in the future if we are having issues.