TSQL 单元测试工具 2017：SQL Server Data Tools 2017 与 tSQLt

Question

我有一个新项目需要 SQL Server 单元测试，以及带有 VSTS 的 CI/CD。

以下是需要的功能

• 针对存储过程的 SQL 服务器单元测试，为每个测试设置初始目标表并进行清理

• sql 中的单元测试

• 带有 VSTS 和 Git 的 CI/CD

• 设置简单，使用方便

我查看了 SSDT 2017，看起来不错。但它似乎缺乏一个功能，即可以在预测试步骤中的每个测试之间轻松共享通用设置脚本。它可能缺少其他应可用于日常使用的功能。但我可能错了。

2017 年哪种工具更适合一般的 sql server 单元测试？

SQL Server Data Tools for Visual Studio

TSQLT

Answer 1

没有更多用于 SQL 开发的单元测试解决方案的原因之一是，正确的单元测试对于数据库来说本来就更难，所以人们不会这样做。这是因为数据库维护状态以及引用完整性。想象一下为一个存储过程 (order_detail_update_status) 编写一个单元测试，它会更新 order_detail 表上的状态标志。 order_detail 表依赖于order_header 和product 表，order_header 又具有customer 和employee 的外键，而产品表可能依赖于product_category、product_type 和supplier。也就是说，至少需要用有效数据填充七个表（可能更多）才能编写一个测试，而除了其中一个表之外，所有表都与被测代码无关。

因此，您应该在单元测试解决方案中寻找的正是——以最少的设置测试离散代码单元的能力。因此，理想情况下，您可以只在 order_detail 中设置所需的测试数据，而忽略其余的表格 - 我知道只有一个测试框架允许您这样做。

此外，单元测试应该有最小的失败原因，在上面的例子中，order_detail_update_status 只是更新 order_detail 表上的一行。如果将新的非空列添加到客户表中，而该列未由测试设置处理，那么您会遇到一种情况，即我们的测试可能由于完全不相关的原因而失败。这使得测试变得非常脆弱，并且在交付期限紧迫的压力下，开发人员将很快放弃编写和维护测试。

一套单元测试应该可以按任何顺序运行，没有相互依赖关系，一个好的测试框架应该支持这一点，以及设置、拆卸和支持模拟对象（可能是也可能不是同一部分的一部分）框架）。在上述场景中，如果您不想花费大量时间修复无缘无故失败的测试，那么模拟 order_detail 表以测试仅涉及 order_detail 表的模块的能力是最重要的功能之一“好”的理由。

因此，就您的要求和上述几点而言，我知道只有一个框架可以完成所有这些工作 - tSQLt。这是基于现实世界的经验——我们在我的上一个项目中进行了 6,000 多个 tSQLt 单元测试。它包括以下功能：

• 单元测试存储过程、函数和视图
• 模拟表、视图和函数
• 模拟（或间谍）存储过程 - 用于隔离， 回放或预定义结果
• 套件设置
• 自动拆卸（因为每个测试都以自己的翻译运行）
• 单元测试是完全隔离的，可以按任意顺序执行

它与 CI/CD 中的 VSTS 配合得非常好，而且由于所有单元测试都是用 T-SQL 编写的，因此非常易于使用。

在 Visual Studio 中使用 tSQLt 的最佳方式是使用复合项目 - 其中应用程序数据库对象和模块在一个项目中维护，而 tSQLt 框架和所有单元测试是第二个项目的一部分。有一篇很好的文章可以让您开始使用 here。

我在几年前为Simple-Talk 写了一篇关于 tSQLt 的好处的更详细的文章，这也可能会有所帮助

Answer 2

请注意，Microsoft 正在推广 slacker，请参阅例如Channel 9: SQL Server Database Unit Testing in your DevOps pipeline。我们发现它在 Azure SQL 设置中运行良好。对于 Azure SQL 上的 tSQLt，我记得一些关于启用 CLR 和 TRUSTWORTHY 选项的问题，但也看到它应该仍然可以工作，例如这里：

• Nikolai Thomassen: Azure SQL unit testing with tSQLt using Azure DevOps
• SQLShack: SQL unit testing with the tSQLt framework for beginners

Answer 3

你可以重复使用脚本，你可以做很多事情。只需使用 tSQLt 即可快速回答您的问题。到目前为止，没有其他单元测试框架比 tSQLt 更强大/灵活且易于使用。刚开始使用，就是这样。 SSDT 中的设置非常简单快捷。 @datacentricity 为您写了足够多的关于该框架的文章，如果您想了解更多信息，请阅读他提供的文章。

如果您按照 tSQLt 的方向发展，我将添加一些内容让您的生活更轻松：

• 对所有跨数据库或链接对象使用同义词；
• 使用 SSMS 中的标准脚本创建所有 tSQLt 对象，然后将对象导入 SSDT
• 为 tSQLt 对象创建单独的项目并将其标记为“相同的数据库”作为您愿意测试的数据库
• 在 tSQLt 项目中创建 pre-script 并从那里运行 原始 数据库项目的 pre-script
• 在 tSQLt 项目中创建 post-script 并从那里运行 原始 数据库项目的 post-script
• 在 tSQLt 后置脚本中作为最后一条语句写入“EXEC tSQLt.RunAll”
• 在 tSQLt 项目中创建发布脚本，并在设置中确保它将部署“扩展属性”
• 确保所有测试类（模式）都有扩展属性语句

可能还有一些其他的细微差别，但只是从一些东西开始，我很确定你很快就会开始爱上 tSQLt。