AWS CDK is a tool that allows developers to define their infrastructure as code in popular programming languages, rather than yaml config files.
Using python with AWS CDK and Lambda functions lets you define, build, and test an application from the ground up in a single codebase. Tools within the python ecosystem like black, pylint, and pytest can allow your infrastructure and application to have a unified style, automatic testing, and inline documentation.
Project Structure
When working with pytest, it's recommended to use a "src" directory, as recommended in this post in ionel's blog. Our project layout then looks like:
In setup.py, we need to point package_dir and packages to our src directory:
# setup.py
""" Project installation configuration """
from setuptools import setup, find_packages
setup(
name="app_name",
version="0.1.1",
packages=find_packages("src"),
package_dir={"": "src"},
author="Author Name",
author_email="author@domain.com",
)
Then, we can install an editable version of our project for development by running:
pip install -e . Now tests in tests/ should be able to reference our application's modules through absolute imports like from app_name import app .
Getting Started with Testing
Setting up tests with pytest is fairly straightforward. in the tests/ toplevel directory, create a file called conftest.py. In the file, be sure to import pytest and add in a simple test:
""" Simple pytest configuration """
import pytest
def test_conf():
""" Assert tests are configured """
assert True
To run our test suite, we can use the pytest command:
pytest tests
=================================================================================== test session starts ===================================================================================
platform darwin -- Python 3.8.2, pytest-5.4.1, py-1.8.1, pluggy-0.13.1
rootdir: /path/to/your/app/tests/
collected 1 item
tests/conf_test.py . [100%]
==================================================================================== 1 passed in 0.01s ====================================================================================
This will run all tests in the tests directory. Add additional tests for modules, functions, and classes and make sure they pass!
As you add tests, you may come across cases where certain functions have side effects, like posting to an API. There's a way to mitigate that- through monkeypatching and dummy objects.
DummyClient- Testing Without Side Effects
To prevent our project from provisioning resources during testing, we created a DummyClient class, with a single method- do_nothing(), and overrode the __getattr__() method to point all undeclared attributes to that method:
# dummy_client.py
class DummyClient(object):
...
def do_nothing(self, *args, return_value=None, return_none=False, **kwargs):
if return_none:
return None
elif return_value is not None:
return return_value
return self.default_return_value
def __getattr__(self, attr):
return self.do_nothing
The do_nothing() method accepts any number of positional and/or keyword arguments, and returns DummyClient.default_return_value unless return_value or return_none are specified in a function call. That means we can have a single client that can "pretend" to run any method (regardless of signature) without additional configuration.
Monkeypatching
To use our dummy client instead of library clients (like requests or boto3), we can take advantage of the monkeypatch fixture in pytest. This allows us to replace the requests or boto3.client objects with instances of our dummy client during particular tests.
# test_lambda.py
from collections import namedtuple
import pytests
import requests
from app_name.resources import DummyClient
from app_name.resources.services.some_lambda import lambda_handler
def test_send_request(monkeypatch):
client = DummyClient('requests.post')
response_class = namedtuple('Response', ['json','body', status_code])
client.default_return_value = response_class(
json={'foo':1},
body='{"foo": 1}',
status_code=200,
)
monkeypatch.setattr(requests, 'post', client.post)
response = lambda_handler(event={}, context=object())
assert response.get('status_code') == 200
With this patch, the post method is never invoked, and instead our DummyClient.do_nothing method. The return value here is a named tuple, rather than a requests.Response, but our application code only needs to now that there's a status_code and body attribute.
Leveraging pytest Fixtures
One common task for a lambda function is to use boto3 to fetch some data about a resource, do some transformations to it, then send the new data to another service or resource. Many services will receive events from the same sources (e.g. s3, SQS, EventBridge, etc.), and those events will share a common schema. If we move our events from being tied directly to a specific test into a common event store, we can reduce redundancy in our testing suite:
// events.json
{
"events": {
"empty_event": {
"event": {},
"metadata": {},
},
"200_ok": {
"event": {
"statusCode": 200,
"body": "some content"
},
"metadata": {}
},
... more events ...
}We refactored our tests to include tests/events.json , a file that storing sample events from each source of data, as well as some generic events (empty event, 500 response, etc.). To get those events passed to tests, we utilize a project-scoped fixture in conftest.py that loads all test events into memory at the start of testing. We can then utilize pytest's parameterize to specify which events we want to test. While we're at it, we can start using a fixture for the "context" object that AWS passes to each lambda:
# conftest.py
import json
import pytest
with open('events.json', 'r') as f:
event_dict = json.loads(f.read())
@pytest.fixture
def events():
return event_dict['events']
@pytest.fixture
def context():
return object()
# test_handler.py
import pytest
from app_name.resources.some_lambda import lambda_handler
@pytest.mark.parametrize('event_name', ['empty_event', '200_ok'])
def test_handler(events, event_name, context):
event = event[event_name]['event']
expected_response = event[event_name]['metadata']['expected_response']
response = lambda_handler(event, context)
# should get a 200 response
assert response.get('statusCode') == 200
# should get a response body that isn't empty
assert response.get('body')
This lets us easily test a function with a number of different events without duplicating logic across tests- adding a new event to a test is as easy as adding its name to the parametrize list argument.
Conclusion
Leveraging features of pytest, we can test not only our function code, but the infrastructure itself, all in one code repository. By testing your entire stack with the same codebase, you can ensure your application is well maintained, that infrastructure is deployed correctly, and that your configuration and codebase are documented in the same place. ##
