Skip to content

Tests do not load .env or serverless.yml variables #51

Open

Description

@Steffan-Carlos

On newest release when running npm test which runs serverless-bundle test environment variables from serverless.yml

provider:
  name: aws
  runtime: nodejs10.x
  stage: dev
  region: us-east-1
  environment:
    TEST: "value"

or from .env file

TEST=value

This issue was noticed in the serverless-bundle package and noted by @Vadorequest
AnomalyInnovations/serverless-bundle#4

Using his solution I was able to load .env variables by adding the following to the package.json

"jest": {
    "setupFilesAfterEnv": [
      "./jest-preload-env.js"
    ]
  }

jest-preload-env.js

require('dotenv').config({
    path: './.env'
});

if (process.env.NODE_ENV !== 'test') {
    throw Error('Non-test environment');
}

severless-bundle test should load serverless.yml environment variables

Activity

  1. jayair commented on Oct 26, 2019

    @jayair
    Member

    Oh good catch. Yeah I'll have a look at how to do this in the serverless-bundle plugin.

  2. Steffan-Carlos commented on Nov 22, 2019

    @Steffan-Carlos
    Author

    @jayair Any update on this issue?

  3. jayair commented on Jan 2, 2020

    @jayair
    Member

    Yeah I just pushed a beta version. Give it a try!

  4. jeff-kilbride commented on Feb 18, 2020

    @jeff-kilbride

    Environment variables are working for me in tests, but the sample docs are a bit confusing. In the sample serverless.yml file, you have:

      #environment:
      #  sampleEnvVar: ${env:SAMPLE_ENV_VAR}
    

    with the following in the env.example file:

    SAMPLE_ENV_VAR=i-am-an-environment-variable
    

    This leads to a mismatched environment between the code and the tests. In the code, the given environment variable is accessed under process.env.sampleEnvVar. However, the tests seem to be reading directly from the .env file. So, it seems the tests are expecting this variable under process.env.SAMPLE_ENV_VAR. To get it to work correctly, I had to change the format of my environment variables to make them consistent.

    To avoid this confusion, I think the samples should be changed to be consistent also. The sample variable should either be sampleEnvVar or SAMPLE_ENV_VAR in both the .env file and the serverless.yml file.

    Hope this makes sense... :)

  5. jayair commented on Feb 23, 2020

    @jayair
    Member

    @jeff-kilbride Good catch, let me update the sample in the comment.

  6. Steffan-Carlos commented on Apr 17, 2020

    @Steffan-Carlos
    Author

    looks good to me

  7. kevinkoste commented on Jun 4, 2020

    @kevinkoste

    I'm coming across an issue using the same three serverless plugins as serverless-nodejs-starter. My project uses env vars defined in the serverless.yml based on custom serverless variables, like so:

    # serverless.yml
    
    provider:
      environment:
        USERS_TABLE_NAME: ${self:custom.usersTableName}
    
    custom:
      stage: ${opt:stage, self:provider.stage}
      usersTableName: ${self:custom.stage}-myproject-users
    
    // handler that is being tested
    
    dynamoDb.put({
      TableName: process.env.USERS_TABLE_NAME,
      Item: {... }
    })
    

    Ideally, 'serverless-bundle test' would use env vars defined in serverless.yml instead of the .env file itself. Thanks for any ideas - could be missing something basic here.

  8. jayair commented on Jun 13, 2020

    @jayair
    Member

    Hmm it doesn't right now. That's because the .env file is treated as the environment variables of the execution context, while the ones in the serverless.yml are the ones that are set in the Lambda function when it's deployed.

    It's actually a little tricky to do this because serverelss-bundle test is running the tests agains the bundled code and not against what Serverless Framework creates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions