【发布时间】：2010-02-19 00:57:49
【问题描述】：
我们在 TSQL 存储过程中有相当多的逻辑。作为自动化测试的忠实粉丝，我开始为存储过程编写自动化测试。
我通过从 C# 项目中调用存储过程来测试它们。我使所有涉及数据库的测试都从基类继承，以确保测试在从未提交的 TransactionScope 中运行。有几个与此相关的问题：
- 与不接触数据库的测试相比，测试速度较慢，但我认为对此无能为力。
- 有时，当我想在运行测试逻辑之前让数据库进入我需要的状态时，我会遇到 FK 问题。例如。当我需要截断 FK 引用的表时，您不能这样做。我还需要删除引用表中的行。
- 有时我需要编写一个新的存储过程或查询以使数据库进入您需要的状态。另一方面，我经常发现我以后需要一个类似的过程来获得新功能。
尽管有这些缺点，我仍然选择为存储过程逻辑编写测试，因为我们在存储过程中有相当多的逻辑。您是否使用类似的方法、完全不同的方法（例如 TSqlUnit）或者您不费心测试存储过程？
【问题讨论】：
-
这是一个方便的列表，列出了为什么存储过程因价值相对较低而令人痛苦的原因。
-
我曾经在SP阵营中根深蒂固，但我的想法变了。 CRUD 的存储过程很麻烦；使用 OR 映射器和参数化内联查询存储过程似乎不太重要。
-
不幸的是，SP 是我必须使用的，而且恐怕不会改变。
标签： database unit-testing tsql