【发布时间】:2023-02-21 00:07:37
【问题描述】:
我的问题的第 1 部分是:我试图找到仅使用免费的 tSQLt 单独购买 Red Gate SQL Test VS 的好处。 我已经看到 Red Gate 回答了 2 个类似的问题,他们基本上说组织测试的 UI 是主要的好处。
我也在想,也许因为 SQL Test 是付费工具,它的 tSQLt 版本会更好或者具有良好的维护/功能,但后来我在 Red Gate 论坛上看到这篇帖子 (https://forum.red-gate.com/discussion/18049/sql-test-is-over-a-year-behind-tsqlt),其中有用户抱怨 tSQLt SQL Test 的版本比 tSQLt 开源代码落后 2 个版本……所以即使这也不是优势,而且使用 SQL Test 似乎在拥有最新版本的这方面甚至可能是劣势。
有谁知道购买 SQL 测试工具的任何原因吗? 在有许多开发人员可能想要添加单元测试的环境中,是否有人单独使用 tSQLt?
我的问题的第 2 部分是:综上所述,我正在考虑单独使用开源 tSQLt。 我想做的是 -
- 当开发人员创建数据库副本以在其上开发 SQL 代码时,该副本上已经有 tSQLt。
- 开发人员将创建他的测试 SP,然后将它们推送到新“测试”文件夹下的存储库(不会作为版本的一部分部署)
- 当他将创建一个 PR 来添加他的代码时,我们将在管道中创建一个新任务,将“测试”文件夹中的已提交测试部署到我们已经为运行 SQL 代码而生成的数据库中打开(该数据库已经有 tSQLt,而不是仅运行“product”文件夹中的代码,我们还将运行“tests”文件夹中的代码)
- 该任务还将调用 tSQLt.RunAll
(我不是 DevOps 专家,但这基本上是计划,当然我们的 DevOps 将实施并确保使用 SP tSQLt.XmlResultFormatter 清楚地显示测试结果)
你怎么认为? 有没有人做过类似的事情? 我会很感激任何帮助 提前致谢
【问题讨论】: