sql触发器单元测试必须在真实事务上下文中执行并捕获副作用，因触发器无独立入口、不可靠手动验证；postgresql宜用pgtap框架断言行为，mysql需绕权限限制并严格匹配生产版本。
SQL触发器单元测试为什么不能只靠手动验证
触发器逻辑一旦嵌入数据库，就脱离应用层控制，手动 INSERT/UPDATE/DELETE 验证既不可靠又难覆盖边界。真实场景中，BEFORE 和 AFTER 触发器对同一事务内其他语句的影响、多行操作时的逐行触发行为、以及触发器中调用的存储过程错误传播，都容易被肉眼漏掉。
核心矛盾在于：触发器没有独立入口，无法像函数那样直接传参调用。所以测试必须在真实或近似真实的事务上下文中执行，并捕获副作用（如表变更、错误抛出、系统变量修改）。
PostgreSQL 中用 pgTAP 写触发器测试最省力
pgTAP 是专为 PostgreSQL 设计的测试框架，支持在数据库内运行断言，能直接验证触发器是否按预期修改数据、抛出正确错误、或影响 NEW/OLD 行。它不依赖外部语言，避免了 ORM 或连接池引入的干扰。
- 安装只需
CREATE EXTENSION IF NOT EXISTS tap;（需 superuser 权限） - 每个测试用
SELECT * FROM plan(3);声明期望断言数，失败会中断并报错行号 - 用
is()比较查询结果，throws_ok()捕获RAISE EXCEPTION，is_empty()验证未产生冗余插入 - 务必在事务块中执行测试，用
ROLLBACK清理——pgTAP 默认不自动回滚，否则污染后续测试
示例：测试一个防止负余额的 BEFORE UPDATE 触发器
SELECT plan(2); INSERT INTO accounts (id, balance) VALUES (1, 100); SELECT throws_ok($$UPDATE accounts SET balance = -50 WHERE id = 1$$, 'P0001', 'balance cannot be negative'); SELECT is((SELECT balance FROM accounts WHERE id = 1), 100, 'balance unchanged after invalid update'); SELECT * FROM finish();
MySQL 触发器测试得绕开权限和语法限制
MySQL 不支持在函数或存储过程中直接调用触发器，且 TRIGGER 权限常被 DBA 收紧。更现实的做法是：在测试库中启用 log_bin = OFF（避免 binlog 冲突），用应用层驱动执行 DML 并检查结果。
- 必须显式开启事务并手动
ROLLBACK，MySQL 的AFTER触发器在 autocommit=ON 下会立即生效 - 避免用
SELECT LAST_INSERT_ID()等非确定性函数断言，它们在触发器内行为不稳定 - 若触发器调用
INSERT INTO audit_log，测试时先清空该表再执行主操作，再查audit_log行数和内容 - 注意 MySQL 8.0+ 对
NEW在BEFORE DELETE中不可访问，老版本却允许——测试环境版本必须与生产一致
触发器测试最容易被忽略的三个点
不是所有触发器都适合“测完即删”。有些逻辑依赖状态（比如累计计数器）、有些涉及跨表约束、有些在复制环境中行为不同。这些不会在单条 SQL 测试里暴露。
-
INSERT ... SELECT批量插入会触发 N 次，但某些触发器误写成只处理单行（如漏掉FOR EACH ROW）——必须用多行数据测试 - 触发器里调用的自定义函数若含
SELECT ... FOR UPDATE，在测试事务中可能死锁，需在测试前加SET innodb_lock_wait_timeout = 1; - PostgreSQL 的
EXECUTE 'INSERT ...' USING NEW.id;动态语句，无法被 pgTAP 的静态分析覆盖，必须实际执行并查目标表
真正可靠的触发器测试，从来不是证明“它能跑”，而是证明“它在所有它该介入的地方，不多不少，不偏不倚地介入”。
