使用Moto测试Lambda时DynamoDB未被正确Mock问题求助

这种场景完全可以通过Moto实现正常Mock，你猜测的两个问题确实是核心根因，按以下步骤调整即可解决：

问题根因 #

• 模块级资源初始化时机错误：DB工具类中的dynamodb、table变量是模块加载时直接初始化的，若初始化时机早于Moto mock启动的时间，会直接生成真实的boto3客户端，不会走Mock逻辑。
• 环境变量缺失：测试运行环境未配置MAIN_TABLE环境变量，导致DB工具类初始化时Table名称为None，无法匹配你在fixture中创建的测试表。
• 冗余Mock配置：fixture中已经通过上下文管理器启动了mock_dynamodb2，测试函数上额外加的@mock_dynamodb2装饰器会导致上下文冲突。

修复步骤 #

步骤1：提前配置测试所需环境变量 #

在conftest.py中新增自动执行的fixture，提前注入MAIN_TABLE环境变量：

import os
import pytest

@pytest.fixture(scope="module", autouse=True)
def set_test_env():
    os.environ["MAIN_TABLE"] = "MAIN_TABLE"
    yield
    del os.environ["MAIN_TABLE"]

步骤2：清理冗余Mock配置 #

删掉测试函数上的@mock_dynamodb2装饰器，避免上下文冲突。

步骤3：确保业务代码导入时机晚于Mock启动 #

保持你现在在测试函数内部才导入lambda_handler的写法，不要在测试文件顶部导入任何依赖DB工具类的业务模块，确保导入业务代码时Moto Mock已经完全启动。

步骤4（推荐）：优化DB工具类为懒加载模式 #

如果不想调整业务代码，做好前三个步骤也可解决问题。懒加载优化属于长期稳妥方案，可以从根本上避免初始化时机问题，防止后续同类测试出现同类错误：

import os
import boto3
from botocore.exceptions import ClientError
import logging

# 移除模块级的初始化逻辑，改为懒加载
_dynamodb = None
_table = None

def _get_table():
    global _dynamodb, _table
    if not _dynamodb:
        _dynamodb = boto3.resource('dynamodb')
    if not _table:
        _table = _dynamodb.Table(os.environ.get("MAIN_TABLE"))
    return _table

def read_item(key: Dict):
    try:
        return _get_table().get_item(Key=key)
    except ClientError as e:
        logging.exception(e)
        raise exceptions.DatabaseReadException(f"Error reading from db: {key}") from e

调整后测试代码示例 #

import json

def test_lambda_handler(get_assets_event, dynamodb, dynamodb_table):
    # Mock启动完成后再导入业务代码
    from [...] import lambda_handler

    response = lambda_handler(get_assets_event, "")
    data = json.loads(response["body"])

    assert response["statusCode"] == 200
    assert "message" in response["body"]
    assert data["message"] == "hello world"

内容的提问来源于stack exchange，提问作者AciD