【问题标题】:Unit Testing TSQL单元测试 SQL
【发布时间】:2014-10-12 10:41:47
【问题描述】:

有没有人为他们的 TSQL 存储过程、触发器、函数...等编写单元测试。

我最近开始制作数据库并恢复和安装我们自动化巡航控制构建过程的一部分。现在我正在考虑将其提升到我们进行安装的下一个级别,然后运行存储过程测试列表等。

我打算自己使用 MsBuild Extensions 来调用测试。但是我知道http://www.tsqltest.org/http://tsqlunit.sourceforge.net/。我也知道 TFS 有 sql 测试。

我只是想看看现实世界中的人们在做什么,他们是否有什么建议。

谢谢

【问题讨论】:

  • Richard,我编写了 TSqlTest,很乐意回答有关它的任何问题。我的电子邮件在网站上可用。
  • tsqltest.org 站点的链接不正确,它重定向到一些花哨的中文?网站。

标签: sql-server unit-testing tsql testing


【解决方案1】:

关键部分:

  • 使其与您的构建/测试自动化集成(这样您就有了一个 您的构建中的绿色或红色)
  • 轻松添加新测试
  • 让您的测试保持最新

高级:

  • 测试代码中的失败条件
  • 确保您的测试在之后清理 他们自己(TSqlTest 的例子 脚本使用 @beforeCount 和 @afterCount 变量来验证 清理)

【讨论】:

  • tsqltest.org 站点的链接不正确,它重定向到一些花哨的中文?地点。也许你应该推荐它应该指向的地方。
  • tsqltest.org 不再活跃。
【解决方案2】:

存储过程。我一般在 SP 头的 cmets 中包含测试查询,并记录正确的结果和查询时间。然而,这仍然是一个手动练习。)

函数。同样,将 SQL 语句放在具有相同信息的标题中。

触发器。我避免使用它们的原因有很多,其中一个原因是与将相同的逻辑放在另一层相比,它们很难测试和调试,但收益很少。这就像问如何测试参照完整性。

但是,这仍然是一个手动过程。但由于我认为应该有意将 SQL 工件设计为完全解耦(例如,没有 SP 调用 SP,与函数相同,以及另一个针对触发器的攻击恕我直言),它相对不那么复杂。

【讨论】:

    【解决方案3】:

    我在这里的一个项目中使用了 Visual Studio 2008 数据库版中内置的数据库测试。它运行良好,但感觉更像是 Visual Studio 的第三方插件,而不是原生组件。我感受到的一些痛苦是:

    • 由于 SQL 代码位于 res 文件中,并且单个代码文件可以包含多个测试,因此根据表/列名称搜索测试并不容易。
    • 因为多个测试存在于同一个代码文件中,所以您会遇到一些恼人的变量名称冲突(例如,如果您在一个代码文件中有两个测试,那么这些测试的所有断言都必须具有唯一的名称;这意味着您的断言名称可能看起来像“testname_assertionname”,实际上没有必要)。
    • 重构测试并不容易 - 例如,如果您想将测试从一个代码文件移动到另一个代码文件,最简单的方法是在新文件中从头开始创建测试,因为测试中有一些零碎的内容散落在res文件和代码文件中。

    所有这一切,正如我开始的那样 - 它确实运作良好。不幸的是,我们还没有将这些测试添加到我们的持续集成服务器中,所以我无法评论自动化运行这些测试有多么容易。我们将 TFS 用于 CI,我假设测试的自动化与标准单元测试的自动化非常相似;换句话说,似乎应该有一个 MSTest 命令行来运行测试。

    当然,如果您获得了运行 Visual Studio 2008 DB 版的许可(据我所知,它现在包含在 VS 2008 Pro 许可中),这只是一个选项。

    【讨论】:

      【解决方案4】:

      我已经在 java 中使用 dbunit 完成了这项工作。

      基本上,您在数据库中执行的任何操作: 返回一个结果集 或更改数据库的状态。

      数据库的状态可以描述为一个数据库所有模式中所有表中所有行中的所有值;任何子集的状态是受某个测试影响的所有数据的状态。

      因此,从一个包含足够测试数据的数据库开始,您可以执行测试,称之为基线。使用 dbunit 或您选择的工具提取快照。

      鉴于您的数据库处于基线,任何结果集都是确定性的(只要您的 sp 是确定性的,如果它执行“select random();”则更少)。

      获取所有 SP 的基线结果集,使用 dbunit 或您正在使用的任何工具将它们保存为快照。

      要测试不改变状态的操作,只需测试你得到的结果集是你最初得到的那个。要测试更改数据库的操作,请测试基线 + 操作 = 预期更改。在每次可能更改数据库的测试之后,将其恢复到基线。

      基本上,恢复到基线的能力使测试成为可能。

      【讨论】:

        【解决方案5】:

        您是否尝试过使用 red-gate.com API?

        他们有一堆产品用于比较 SQL Server 中的事物,并且 API 以编程方式允许几乎相同的功能。

        http://help.red-gate.com/help/SQLDataCompareAPIv5/4/en/GettingStartedAPI.html

        【讨论】:

          猜你喜欢
          • 2019-08-06
          • 2021-10-31
          • 1970-01-01
          • 1970-01-01
          • 2020-02-16
          • 2010-09-14
          • 2019-03-12
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多