Let's say you have some Python application code which connects to Amazon S3 which retrieves the keys in a bucket. Very likely, the application would be using boto and the code would like this:

import boto

def get_s3_conn():
    return boto.connect_s3('<aws-access-key', '<aws-secret-key>')

def list_keys():
    s3_conn = get_s3_conn()
    b = s3_conn.get_bucket('bucket_name')
    keys = b.list()
    return keys

The corresponding test would presumably use some mocks and patching. Here is one way to write a test for the above code:

# Assume the code above is in a module list_keys
# in a function list_keys

from list_keys import list_keys

from mock import patch, Mock

def test_list_keys():
   mocked_keys = [Mock(key='mykey1'), Mock(key='key2')]
   mocked_connection = Mock()
   # Start with patching connect_s3
   with patch('boto.connect_s3', Mock(return_value=mocked_connection)):
       mocked_bucket = Mock()
       # Mock get_bucket() call
       mocked_connection.get_bucket = Mock(return_value=mocked_bucket)
       # Mock the list() call to return the keys you want
       mocked_bucket.list = Mock(return_value=mocked_keys)
       keys = list_keys()

       assert keys == mocked_keys

I thought I really had no other way to get around mocks and patches if I wanted to test this part of my application. But, I discovered moto. Then life became easier.

Using moto's S3 support, I don't need to worry about the mocking and patching the boto calls any more. Here is the same test above, but using moto:

from list_keys import get_s3_conn, list_keys
from moto import mock_s3

def test_list_keys():

    expected_keys = ['key1', 'key2']

    moto = mock_s3()
    # We enter "moto" mode using this

    # Get the connection object
    conn = get_s3_conn()

    # Set up S3 as we expect it to be
    for name in expected_keys:
        k = conn.get_bucket('bucket_name').new_key(name)

    # Now call the actual function
    keys = list_keys()
    assert expected_keys == [ for k in keys]

    # get out of moto mode

Unless it is obvious, here are two major differences from the previous test:

We don't mock or patch anything

The point #1 above is the direct reason I would consider using moto for testing S3 interactions rather than setting up mocks. This helps us in the scenario in which this section of the code lies in another package, not the one you are writing tests for currently. You can actually call this section of the code and let the interaction with S3 happen as if it were interacting directly with Amazon S3. I think this allows deeper penetration of your tests and as a result your code's interactions with others.

The test code has to explicitly first setup the expected state

This may seem like more work, but I think it still outweighs the benefits as mentioned previously.

Please checkout moto here.

If you like this post, please follow PythonTestTips on Twitter.