0

我们正在考虑使用 tSQLt 进行 SQL Server 单元测试，但在这样做之前，我们需要了解我们是否会浪费时间尝试使用我们的设置。我问这个的原因是因为我们有两个数据库，其中一个非常“正常”（这是我们的生产数据库），另一个是“API”数据库，它通过“翻转”的存储过程提供对该数据库的受限访问" 在您访问 API 数据库的用户帐户和生产数据库的模拟帐户之间。生产数据库中的表不是直接访问的，而是通过同义词访问的。事务提供来自 API 数据库中的“入口点”存储过程。

我们希望能够测试两个主要的东西；

(1) 对象的安全权限，因为当我们“忘记”在构建之间正确设置安全访问权限时，我们在使用共享对象时可能会遇到问题。

(2) API 存储过程/函数。我认为我们可以相对独立地测试一些功能，但我看不到存储过程如何轻松工作。

  • tSQLt 是否支持安全权限测试？
  • 我看到跨数据库测试和同义词存在问题，但信息非常具有历史意义。这些现在解决了吗？
  • 为什么 tSQLt 需要 CLR 权限？
  • tSQLt“代码”是否必须安装在要测试的数据库上，还是我们可以在同一实例上的数据库上运行它？
  • 项目清单
4

1 回答 1

1

tSQLt 是否支持安全权限测试？

间接的。您可以使用 ExpectException 和 ExpectNoException 功能来测试给定帐户是否有权访问特定对象。

同义词

AFAIK 你仍然不能伪造指向远程对象的同义词。不过，您可能会更幸运地伪造观点。

为什么 tSQLt 需要 CLR 权限？

如果你的意思是TRUSTWORTY，这不再需要（http://tsqlt.org/748/tsqlt-v1-0-5873-27393-release-notes/）。如果您的意思是“为什么它根本需要 CLR”，这是因为有些操作本身很难或不可能用 T-SQL 完成；看看早期的 tsqlunit 进行勇敢的尝试。

tSQLt“代码”是否必须安装在要测试的数据库上

是的。

我要补充的是，如果您正在测试两个数据库之间的交互，那么区分头发的部门可能会说这不是真正的单元测试。编写一个普通的旧 NUnit/MSTest/whateverUnit 测试可能更容易。过去，我曾在 Nunit 和 Dapper（以 stackoverflow 出名）方面取得了一些运气，可以将轻量级数据库测试放在一起。

于 2016-11-09T19:18:36.930 回答