* docs: Update docs for dashboard providers * docs: Update note on migration Co-authored-by: Maciej Skierkowski <maciej@skierkowski.com>
4.0 KiB
Read this on the main serverless docs site
Testing
Serverless Framework supports defining and running integration tests against lambdas
with HTTP integrations. To get started, assuming we have the default configuration in from the
enterprise-template, you can define a test for
it as follows with a serverless.test.yml file:
- name: hello endpoint returns 200
endpoint:
function: hello
response:
status: 200
Then, when you run sls test (your function must already have been deployed) it will make an HTTP
request against the hello function and pass if the response has a status code of 200:
$ sls test
Serverless Enterprise: Test Results:
Summary --------------------------------------------------
passed - POST hello - hello endpoint returns 200
Serverless Enterprise: Test Summary: 1 passed, 0 failed
If we add a test like this which requires the body to be JSON encoded and contain a key called
foo with the value bar.
- name: hello endpoint returns 200
endpoint:
function: hello
response:
body:
foo: bar
Then when we run sls test we get the details of the failure:
$ sls test
Serverless Enterprise: Test Results:
Summary --------------------------------------------------
passed - POST hello - hello endpoint returns 200
failed - POST hello - hello endpoint returns 2000
Details --------------------------------------------------
1) Failed - hello endpoint returns 200
status: 200
headers: (TRUNCATED)
expected: body = {
"foo": "bar"
}
received: body = {
"message": (TRUNCATED),
"input": (TRUNCATED),
}
Serverless Enterprise: Test Summary: 1 passed, 1 failed
serverless.test.yml specification
The specification file must be an array of objects. Each test is an object in that array. Here is a config file that uses all the options:
- name: hello endpoint returns success # the name of the test. used for running a specific test & in CLI output
endpoint: # this is used to specify which HTTP endpoint / lambda to test against
# specifying only the function name only works if the function has only one HTTP endpoint and
# a specific path & method (i.e. not ANY or {parameterizedUrls})
function: hello
response: true # setting response to true is equivalent to setting it to {status: 200}
request: # this specifies the request to send
headers: # An object mapping to be used as headers on the request
Foo: bar
body: 'foobar' # string literal bodies are used as-is
- name: "hello endpoint returns 'foobar'"
endpoint:
# if specifying both method & path, function is optional
method: POST
path: /hello
response:
body: 'foobar' # setting body to a string literal checks that the response text matches it exactly
- name: hello endpoint returns ok with json request
endpoint:
function: hello
response: true
request:
body: # setting body to an object json encodes it & adds the correct content-type header
foo: bar
blah: baz
- name: hello endpoint returns success with a form request
endpoint:
function: hello
response: true
request:
form: # setting form encodes to a query param, i.e.: ?foo=bar&blah=baz
foo: bar
blah: baz
- name: hello endpoint returns success with a text request
endpoint:
function: hello
response: true
request:
body: 'foobar' # setting body to a string uses it with out any changes
Options
There are 2 options to allow you to avoid running your entire test suite:
--function- only run tests for the function specified. This requires that you've setendpoint.function--name- only run the test with the specified name