Testing

Local

For local testing simple use pytest and build tests for each step of the functionality. There are examples in the code base for how auth is invoked before the relative _get handler is called for either segments or visscore.

Staging / Production

To test via staging (or production) you will need some starter data. For a successful request to our API you will need a legal CASK token. Once you've got this you can hit either API end point - pending on the environment - and get relative data back for your visitor id.

Retreiving valid aid, vid and cask.

The easiest way of retrieving valid tokens is via the simulate tool. It's connected to the same database as the staging Lambdas. A cask can also be generated using a tool in /serverless/tests/gen_cask.py. This tool requires a valid vid.

Auth

The auth function's only roll is to decypher the cask, and check both that the vid inside is the same as the one in the request params, and that the cask is less than 24 hours old. The Function returns an aws policy object that will either allow or deny:

{
    "principalId": "user",
    "policyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "execute-api:Invoke",
                "Effect": "<Allow / Deny>",
                "Resource": "<Arn of Resource trying to be invoked
                    (the lambda in most cases)>"
            }
        ]
    }
}

To test this function pass it a valid vid and cask. These can be generated from ./tests/gen_cask.py (bring your own vid) the auth token does not need aid, as we don't want anything touching our DB's until we are happy they are authenticated.

Visscore / Segmenter Lambdas

Testing these are slightly more complex because there are a few things going on. Similar to the DCS the incoming hit is validated using a schema, any missing params will be requested in the response that is sent back. SQL errors will should not be returned to the client through the API Gateway, but will appear in Cloudwatch / the Lambda Dash / Datadog (if you set this up, be wary of pricing etc)

The worse issue you could have would be timeouts, if the lambda can't connect to a DB then its either a VPC issue or an SG issue. This is quite hard to test so id suggest making a new lambda, giving it the same settings and then manually trying to write code to test what you can or can't connect to, similar to if we had an ec2 that was getting a time out...

Testing visscore-get-[prod/staging]

This Lambda is exposed behind an API Gateway, and can be tested using the following format:

https://k0mdc72zk3.execute-api.eu-west-1.amazonaws.com/staging/visscore?aid=<client>&vid=<vid>&cask=<cask>

Production

Production can be tested in the same way, but the URL format is different:

https://vo4wzmqpj7.execute-api.eu-west-1.amazonaws.com/prod/visscore?aid=<client>&vid=<vid>&cask=<cask>

The Lambda can also be tested via the AWS Lambda admin interface using the following event:

{
  "query": {
      "aid": "<aid>",
      "vid": "<vid>"
  }
}

Testing visscore-auth-[prod/staging] and segments-auth-[prod/staging]

These Lambdas are not exposed directly, but can be tested via the AWS Lambda admin interface using the following event:

{
  "queryStringParameters": {
      "cask": "<cask>",
      "vid": "<vid>"
  },
  "methodArn": "<arn_of_lambda_to_target>"
}

What is methodArn?

The parameter methodArn should be the ARN of the Lambda you want to auth against. Usually this is the visscore-get-staging/segments-get-staging Lambdas. You can find the ARN for these in the AWS Lambda admin interface.

Testing segments-auth-[prod/staging]

This Lambda is exposed behind an API Gateway, and can be tested using the following format:

https://k0mdc72zk3.execute-api.eu-west-1.amazonaws.com/staging/segments?aid=<client>&vid=<vid>&cask=<cask>

Production

Production can be tested in the same way, but the URL format is different:

https://vo4wzmqpj7.execute-api.eu-west-1.amazonaws.com/prod/segments?aid=<client>&vid=<vid>&cask=<cask>

The Lambda can also be tested via the AWS Lambda admin interface using the following event:

{
  "query": {
      "aid": "<aid>",
      "vid": "<vid>"
  }
}