Local test environment

From Izara Wiki
Jump to navigation Jump to search

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:

  1. created in the __test__/unit directory for each serverless project in the repository
  2. 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

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..

  • 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

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

Working documents

Working documents - Local test environment