4. 创建 Mock 表结构：使用临时表模拟外部依赖表、定义表结构与约束

在 Mock 依赖隔离场景中，核心目标是将被测单元与真实的外部表、视图或远端表解耦。通过创建临时表或会话级表结构来模拟外部依赖，可以确保测试在完全受控的环境下运行，不受真实数据变更、权限或网络延迟的影响。

4.1 为什么选择临时表作为 Mock 载体

临时表（TEMPORARY TABLE）在 PostgreSQL 中具备以下天然优势，使其成为 Mock 外部依赖的理想选择：

4.2 定义 Mock 表结构：核心步骤

创建 Mock 表结构通常遵循以下流程，确保与真实依赖表的接口兼容：

1. 分析外部依赖表结构：获取真实表的列名、数据类型、长度、非空约束、主键、唯一约束、外键引用（若需要模拟）。
2. 创建临时表：使用 CREATE TEMPORARY TABLE 定义与真实表相同的列结构，但通常只保留对测试有影响的约束。
3. 定义约束与索引：按需添加主键、唯一约束、检查约束、索引，确保 Mock 表的行为与真实表在查询计划层面一致。
4. 插入 Mock 数据：在测试用例中插入预设的返回数据集或边界值。
5. 验证结构一致性：通过 pg_attribute 或 information_schema 对比 Mock 表与真实表的列差异。

4.3 典型 Mock 表定义示例

假设业务系统依赖一张名为 orders 的外部表（来自远端数据库或另一个 schema），其真实结构如下：

-- 真实表结构（仅作参考，不执行）
CREATE TABLE public.orders (
    order_id      BIGSERIAL PRIMARY KEY,
    customer_id   INTEGER NOT NULL,
    order_date    DATE NOT NULL DEFAULT CURRENT_DATE,
    total_amount  NUMERIC(12,2) NOT NULL CHECK (total_amount >= 0),
    status        VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

在测试会话中，我们创建对应的 Mock 临时表：

-- 创建 Mock 临时表，仅包含测试所需的列和约束
CREATE TEMPORARY TABLE mock_orders (
    order_id      BIGSERIAL PRIMARY KEY,
    customer_id   INTEGER NOT NULL,
    order_date    DATE NOT NULL,
    total_amount  NUMERIC(12,2) NOT NULL,
    status        VARCHAR(20) NOT NULL DEFAULT 'pending'
);

-- 添加检查约束（模拟真实表的 CHECK）
ALTER TABLE mock_orders ADD CONSTRAINT mock_orders_amount_check
    CHECK (total_amount >= 0);

-- 添加索引（若测试涉及 order_date 范围查询）
CREATE INDEX idx_mock_orders_date ON mock_orders(order_date);

-- 注释说明 Mock 用途
COMMENT ON TABLE mock_orders IS 'Mock 表：模拟 public.orders 用于隔离测试';

4.4 使用 LIKE 快速克隆结构

当真实表结构复杂且列较多时，手动定义 Mock 表容易遗漏或写错类型。PostgreSQL 提供了 LIKE 子句，可快速复制表结构：

-- 快速克隆结构（不包含数据）
CREATE TEMPORARY TABLE mock_orders (LIKE public.orders INCLUDING ALL)
ON COMMIT DROP;  -- 事务结束后自动删除

-- 移除不需要的约束（如外键引用真实表）
ALTER TABLE mock_orders DROP CONSTRAINT IF EXISTS orders_customer_id_fkey;

-- 清空自增序列（可选，从 1 开始）
ALTER SEQUENCE mock_orders_order_id_seq RESTART WITH 1;

4.5 Mock 表与真实表的约束差异处理

在隔离测试中，Mock 表不需要完全复制真实表的所有约束，尤其是以下类型需要特别处理：

• 外键约束：通常移除或替换为指向 Mock 表自身的外键，避免依赖其他真实表。
• 唯一约束：若测试不涉及唯一性冲突检测，可移除以减少数据插入限制。
• 检查约束：保留与业务逻辑相关的检查（如金额非负），移除与测试无关的复杂表达式。
• 排他约束：通常移除，因为 Mock 场景很少需要范围排他。

4.6 结构对比与验证

为确保 Mock 表与真实表在接口层面兼容，可以执行以下查询进行自动化验证：

-- 对比列名、数据类型、非空约束
SELECT
    a.attname AS column_name,
    a.attnotnull AS not_null,
    format_type(a.atttypid, a.atttypmod) AS data_type
FROM pg_attribute a
JOIN pg_class c ON a.attrelid = c.oid
WHERE c.relname = 'mock_orders'
  AND a.attnum > 0
  AND NOT a.attisdropped
ORDER BY a.attnum;

将输出结果与真实表的 pg_attribute 查询结果做差集，即可发现缺失或类型不匹配的列。

4.7 Mock 表结构设计模式总结

下表总结了不同依赖类型对应的 Mock 表结构策略：

4.8 常见陷阱与规避

• 序列冲突：临时表使用 BIGSERIAL 时，序列起始值可能受全局序列影响。建议在插入前执行 ALTER SEQUENCE ... RESTART 重置。
• Schema 优先级误解：临时表仅在 pg_temp 在 search_path 中排在目标 schema 之前时才能覆盖同名表。务必检查当前会话的 search_path。
• 事务内可见性：ON COMMIT DROP 的临时表在事务提交后自动消失，适合单事务测试；跨事务测试应使用 ON COMMIT PRESERVE ROWS 或默认行为。
• 权限模拟：临时表不继承真实表的权限设置。若测试涉及行级安全（RLS），需在 Mock 表上显式启用 ALTER TABLE ... ENABLE ROW LEVEL SECURITY。