Local test environment
Overview
Each repository is a micro-service that performs has responsibility for one part of the The Izara Project, although each is meant to be used as part of a network of interconnected micro-services when a single repository is cloned the first level of testing is at the self contained local level.
Unit tests
Most local tests will be unit tests, these tests are built in two ways:
- created in the __test__/unit directory for each serverless project in the repository
- generated from integration tests defined in the Integration Test Config service
Serverless Local
sets up a local api gateway and lambda functions adds environment variable IS_OFFLINE into Lambda functions
lambdas deployed to a local serverless offline environment are invoked by sending REST request to local API Gateway endpoint good for testing API Gateway config bad: cannot setup test environment (eg mocks) in the Jest code because is a separate environment to the serverless offline environment cannot test individual functions that are not API Gateway triggered
add to app serverless.yml below code only needed where functions and api gateway are deployed not needed in resource (if using sns/sqs offline they might need it)
plugins:
- serverless-offline
DynamoDB Local
- https://www.npmjs.com/package/serverless-dynamodb-local
- have setting in powertools dynamo client, if IS_LOCAL (set by serverless offline running) then will add connection settings below
DynamoDB local connection settings are hardcoded, if need to change things like port maybe we can find some hack like local environment variable, rather than polluting serverless.yml etc..
- Serverless have a small module to work with this, we could copy its code if needed:
- https://github.com/99xt/serverless-dynamodb-client/blob/master/index.js
- thinking if starting multiple services together on local can use the same dynamodb local database, just placing multiple tables in it
- default is to store data in memory, which gets destroyed each time we stop, if this becomes unmanageable or if we want to maintain state it is possible to save to file
- to install into a project, in resource dir:
npm install --save-dev serverless-dynamodb-local
- all resource serverless.yml have below code, used only for DynamoDB local
- (not sure) we do not migrate or seed here because we want to do that per service (eg in a script), and might have different seeds for different situations
custom:
dynamodb:
# If you only want to use DynamoDB Local in some stages, declare them here
stages:
- Dev
start:
port: 8000
inMemory: true
heapInitial: 200m #not sure correct setting, can leave off
heapMax: 1g #not sure correct setting, can leave off
migrate: true
seed: true
seed:
default:
sources:
- table: ${self:custom.resourcePrefix}Config
sources: [../app/__test__/dynamodb_seed_data/default/Config.json]
One Time Setup
DynamoDB Local
- install DynamoDB Local in one services resource dir, this only has to be done once then can be used by all services
this downloads dynamodb-local from aws and sets up
sls dynamodb install
- requires JDK/JRE, eg: sudo apt-get install openjdk-{version}-jdk
Troubleshooting
- DynamoDB local java executable appears to be saved into repositories /.dynamodb folder
- If have trouble the downloaded dynamodb file might be no good, can download from https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.DownloadingAndRunning.html
- Copy into repositories /.dynamodb folder
- Might need to change permissions to eg: 777
Per Session / Per Reboot
Start an empty instance of DynamoDB
- can by in any services resource dir:
sls dynamodb start
- this will also migrate and seed this service
DynamoDB (if working on multiple services)
- Can seed multiple services into the local DynamoDB instance
- resource dir of additional services:
sls dynamodb migrate
sls dynamodb seed
Multiple Dynamo Seed groups
- if service has multiple seed groups, to only seed the default group:
sls dynamodb start --seed:default