Local test environment: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
(Created page with "= Overview = Each repository is a micro-service that performs has responsibility for one part of the Izara Project, although each is meant to be used as part of a network of...")
 
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Overview =
= Overview =


Each repository is a micro-service that performs has responsibility for one part of 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.
Each repository is a micro-service that performs has responsibility for one part of the {{ProjectNameLong}}, 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 =
= Unit tests =


Most local tests will be unit tests, these tests are built in two ways:
Most local tests will be unit tests, these tests are built in two ways:
Line 10: Line 10:
# generated from integration tests defined in the [[Service - Integration Test Config|Integration Test Config]] service
# generated from integration tests defined in the [[Service - Integration Test Config|Integration Test Config]] service


= Serverless Local (?) =
= 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)
 
<syntaxhighlight lang="YAML">
plugins:
  - serverless-offline
</syntaxhighlight>


= DynamoDB Local =
= 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:
<syntaxhighlight lang="Bash">npm install --save-dev serverless-dynamodb-local</syntaxhighlight>
 
* 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
 
<syntaxhighlight lang="JavaScript">
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]
</syntaxhighlight>
 
== 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
<syntaxhighlight lang="Bash">sls dynamodb install</syntaxhighlight>
 
* 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:
 
<syntaxhighlight lang="Bash">
sls dynamodb start
</syntaxhighlight>
 
* 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:
 
<syntaxhighlight lang="Bash">
sls dynamodb migrate
sls dynamodb seed
</syntaxhighlight>
 
=== Multiple Dynamo Seed groups ===
 
* if service has multiple seed groups, to only seed the default group:
 
<syntaxhighlight lang="Bash">
sls dynamodb start --seed:default
</syntaxhighlight>
 
= Working documents =
 
[[:Category:Working documents - Local test environment|Working documents - Local test environment]]

Latest revision as of 09:29, 9 May 2022

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