Testing

Libraries and patterns used to test the Moped API

Pytest library

The Pytest framework is used to write and run the tests for the API.

unittest.mock library

The unittest.mock library is used to replace parts of code that are not relevant to a test. For example, for the protected routes in the User Management API, unit tests are written for the helpers that check for valid user attributes and user roles. After testing these helpers independently, there is no need to test them again in tests for the protected routes.

The return values of these checks can be patched using patchers and/or the Mock class. These tools help tests focus on specific aspects of a method and avoid complicated logic that is unrelated to the test.

Test implementation

The base of the test implementation is the TestApp class that instantiates a test client that can be exposed within tests through self.client. The test client is an instance of the Werkzeug Client class documented here. Through the client, tests can make requests to the Flask app as one would from it on a local or hosted server. More details can be found in the Test Driven Development section of the Moped API readme.

Extending the TestApp class

In order to create tests for different Flask blueprints of the API, a new class that inherits TestApp can be created and written in a separate Python file. For example, to test the users blueprint, create a new file called test_users.py within the /tests/ folder. In that file, a new class called TestUsers can be defined.

class TestExamples(TestApp):
    def test_example(self):
        """Test that tests something."""
        result = test_something(arg)

        assert result is True

Testing AWS resources

In order to test API routes that employ AWS resources, the moto library is used to mock AWS resources and isolate any side effects of the tests away from the staging or production AWS environments.

It is important to take the documented precautions in order to avoid accessing live AWS resources from the test environment.

An important pattern to successfully test AWS resources is mocking a resource, seeding it with any needed data, and then patching boto method calls with moto. As an example, to test a route or method that sends a request to a Cognito user pool, a test user pool with mock users must be initialized prior to patching the boto methods in that route. The patched boto methods will then interact with the mocked user pool for CRUD actions.

The easiest way to start tests with a mocked resource already initialized is with Pytest fixtures as documented in the moto usage example. These fixtures allow individual tests to access a reusable and consistent mocked AWS resources and avoid repetition in tests that use the same AWS resources.