Как тестировать облачный код без счетов от AWS

Представьте ситуацию: вы пишете сервис, который должен складывать отчеты в S3, обновлять записи в DynamoDB и отправлять уведомления через SNS. Все идет отлично, пока не встает вопрос тестов. Поднимать реальную инфраструктуру в облаке под каждый прогон CI — дорого и медленно. Использовать обычные моки (unittest.mock) — то еще удовольствие, потому что приходится вручную описывать структуру ответов от API, которая у AWS бывает весьма заковыристой.

Я часто сталкивался с тем, что разработчики либо вообще не тестят интеграцию с облаком, надеясь на авось, либо пишут тонны хрупкого кода для имитации ответов. Проект Moto предлагает элегантный выход: он просто перехватывает запросы к AWS и обрабатывает их локально.

Что такое Moto и зачем он в вашем стеке

Moto — это библиотека на Python, которая умеет притворяться настоящим AWS. Она не просто возвращает пустые заглушки, а имитирует состояние ресурсов. Если вы создали бакет через Moto, а потом попытались положить туда файл — файл там действительно «появится» во время выполнения теста.

Это не полноценная замена облаку для продакшена, но для юнит-тестов и интеграционных проверок — вещь незаменимая. Проект живет с 2013 года, набрал больше 8 тысяч звезд и поддерживает практически все популярные сервисы: от EC2 и S3 до Lambda и Kinesis.

Как это работает на практике

Самое приятное в Moto — порог входа. Вам не нужно менять логику подключения к AWS в основном коде. Достаточно обернуть тестовую функцию декоратором.

Допустим, у вас есть такой класс для работы с S3:

import boto3

class ReportStorage:
    def __init__(self, bucket_name):
        self.bucket_name = bucket_name
        self.s3 = boto3.client("s3", region_name="us-east-1")

    def save_report(self, filename, data):
        self.s3.put_object(Bucket=self.bucket_name, Key=filename, Body=data)

Чтобы протестировать этот метод, не создавая реальный бакет в аккаунте компании, пишем такой тест:

import boto3
from moto import mock_aws
from my_app import ReportStorage

@mock_aws
def test_report_saving():
    # Внутри этого блока boto3 не пойдет в интернет
    s3 = boto3.resource("s3", region_name="us-east-1")
    s3.create_bucket(Bucket="my-reports")

    storage = ReportStorage("my-reports")
    storage.save_report("daily_stats.txt", "some data")

    # Проверяем, что файл действительно "сохранился" в виртуальном S3
    obj = s3.Object("my-reports", "daily_stats.txt").get()
    assert obj["Body"].read().decode("utf-8") == "some data"

Декоратор @mock_aws делает всю магию: он подменяет эндпоинты boto3 на локальные обработчики Moto. Как только тест завершается, всё «состояние» облака стирается, и следующий тест начинает с чистого листа.

Почему это удобнее обычных моков

Когда мы используем стандартный patch, мы тестируем не логику взаимодействия, а то, что наш код вызвал определенный метод с определенными аргументами. Moto идет дальше.

1. Состояние ресурсов. Вы можете создать очередь SQS в одном методе, отправить туда сообщение в другом и прочитать его в третьем. Moto сохранит это сообщение внутри себя.
2. Проверка ошибок. Хотите проверить, как приложение ведет себя, если бакета не существует? Moto выбросит ровно то же исключение ClientError с тем же кодом ошибки, что и настоящий AWS.
3. Никаких реальных ключей. Вам не нужны AWS_ACCESS_KEY_ID или AWS_SECRET_ACCESS_KEY. Moto достаточно любых фиктивных строк, чтобы библиотека boto3 не ругалась при инициализации.

Режимы работы

Moto можно использовать тремя способами в зависимости от ваших задач.

Первый — декораторы, как в примере выше. Это самый быстрый путь для Python-разработчиков.

Второй — контекстные менеджеры. Удобно, если мок нужен только в части функции:

with mock_aws():
    # тут работаем с виртуальным AWS
    pass

Третий — запуск в виде отдельного сервера (Standalone Server). Moto умеет подниматься как Flask-приложение. Это киллер-фича, если вы пишете на Java, Go или Node.js, но хотите использовать наработки Moto для тестов. Вы просто перенаправляете запросы своего SDK на localhost:5000.

Нюансы и ограничения

Несмотря на крутость, Moto — это имитация. Она не гарантирует 100% идентичности поведения AWS. Например, задержки сети, лимиты (throttling) или специфические политики IAM там реализованы не полностью или не реализованы вовсе.

Также стоит заглядывать в список поддерживаемых сервисов (Implementation Coverage). Основные вещи типа S3, EC2, RDS покрыты отлично, но если вы используете какой-нибудь экзотический сервис, который AWS анонсировал на прошлой неделе, Moto может о нем еще не знать.

Кому стоит попробовать

Если вы используете Python и boto3, Moto должна быть в вашем requirements-dev.txt по умолчанию. Она экономит время на написании бойлерплейта для тестов и, что немаловажно, бережет нервы, когда вы случайно запускаете тесты и понимаете, что забыли прописать переменные окружения, но при этом ничего не сломалось в реальном облаке.

Для тех, кто работает в больших командах, это еще и отличный способ ускорить CI/CD пайплайны. Тесты с Moto летают, потому что всё происходит в оперативной памяти без сетевых задержек.

Начать можно с простой установки: pip install 'moto[s3,ec2]' (можно указать только нужные сервисы, чтобы не тянуть лишние зависимости).

Попробуйте переписать хотя бы один тест с использованием Moto, и возвращаться к ручным мокам вам вряд ли захочется.