sql server 存储过程测试需捕获return值、output参数和结果集三类输出，推荐使用tsqlt框架实现事务内「准备→执行→断言→回滚」闭环，避免数据污染与依赖干扰。

SQL Server 存储过程怎么 mock 输入参数和捕获输出？

SQL Server 本身没有内置的单元测试框架，EXEC 直接调用没法隔离依赖、没法断言结果。真要测，得靠外部工具或手写验证脚本——但核心是：必须绕过事务外的副作用，且能拿到 RETURN 值、OUTPUT 参数、结果集三类输出。

常见错误是只查 SELECT 结果，漏掉 @return_code INT OUTPUT 或游标返回；或者在事务里没 ROLLBACK，导致后续测试数据污染。

• 用 DECLARE @rc INT; EXEC @rc = dbo.usp_GetUserById @id = 123; 捕获返回值
• DECLARE @name NVARCHAR(50); EXEC dbo.usp_GetUserName @id = 123, @name = @name OUTPUT; 必须显式声明变量并加 OUTPUT
• 结果集用临时表承接：SELECT * INTO #expected FROM (VALUES (1,'Alice')) t(id,name); SELECT * INTO #actual FROM OPENROWSET(...) 不现实，改用 INSERT #actual EXEC dbo.usp_ListActiveUsers;

tSQLt 是唯一靠谱的 SQL Server 单元测试方案吗？

是。开源、轻量、基于 T-SQL 实现，不依赖 .NET 或外部进程，所有断言都在数据库内执行，tSQLt.AssertEqualsTable 这类函数直接比对两个表结构+数据，连 NULL 和排序都处理得当。

容易踩的坑是安装权限：需要 db_owner 角色才能运行 tSQLt.Install()；另外它强制要求每个测试用例在独立 schema（如 [test].[test_GetUserById_ReturnsActive]），否则报错 tSQLt.Private_ValidateTestClass。

• 安装后必须执行 EXEC tSQLt.NewTestClass 'test'; 创建测试类 schema
• 测试存储过程名必须以 test_ 开头，且不能有参数（tSQLt 会自动调用）
• 用 tSQLt.FakeTable 'dbo.Users'; 替换真实表，避免读写生产数据
• tSQLt.ExpectException @ExpectedMessage = N'User not found'; 只匹配消息子串，不是完整 error message

PostgreSQL / MySQL 怎么做等效测试？别硬套 tSQLt

PostgreSQL 用 pgTAP，MySQL 用 mysqlt 或纯 SQL 脚本，原理类似但语法差异大。关键不是“有没有框架”，而是能否在事务中完成「准备→执行→断言→回滚」闭环。

比如 PostgreSQL 中，SELECT is((SELECT status FROM users WHERE id = 1), 'active', 'user should be active'); 这种写法看着像断言，但实际执行后不会自动 rollback，必须手动包在 BEGIN; ... ROLLBACK; 里，否则测试跑完数据就留在库中了。

• pgTAP 的 plan 3; 必须放在测试开头，否则 finish(); 会报错
• MySQL 没有原生断言函数，常用 SELECT CASE WHEN COUNT(*) = 1 THEN 'PASS' ELSE 'FAIL' END FROM ... 输出字符串判断，但无法抛异常中断流程
• 所有方案都避不开「结果集转成可比较结构」：要么导出为 CSV 再 diff，要么插入临时表后 EXCEPT 对比

为什么不用应用层测试代替数据库层测试？

因为应用层测不到权限控制、行级安全策略（RLS）、触发器副作用、执行计划退化这些只有数据库引擎才知道的事。比如一个存储过程加了 WITH RECOMPILE，应用层调用看不出性能变化，但 sys.dm_exec_query_stats 里缓存命中率会暴跌。

最常被忽略的是时序问题：多个存储过程依赖同一张中间表，单元测试若没按依赖顺序执行，tSQLt 的 FakeTable 可能被覆盖，导致后续测试用的是空表而非预设数据。

• 测试前清空依赖表，不如用 tSQLt.ApplyConstraint 临时禁用外键，再用 tSQLt.CaptureOutput 拦截 PRINT 输出做日志验证
• 不要在测试里写 WAITFOR DELAY '00:00:01' 模拟并发——它不可靠，改用 tSQLt.SpiedOn 监控被调用次数更准
• 上线前必须跑一次带真实统计信息的集成测试，单元测试再全也 cover 不了参数嗅探引发的执行计划偏差