SSDT项目和管理与已知数据的集成测试

时间:2017-07-03 14:49:16

标签: sql-server integration-testing sql-server-data-tools

我正在迁移到SSDT,以便对包含数据库的大型项目的数据库结构进行模式控制。该项目已经在其内部进行了数百次集成测试,这些测试处于各种脆弱状态。其中许多使用我称之为“已知数据”来执行集成测试。测试依赖于这些数据,以便他们成功运行。

过去,我们已经完成了我们的集成测试数据库的1:1副本,用于在功能分支中进行测试,但我对这个过程不太满意,因为它会给服务器增加膨胀。

使用SSDT,有没有办法将这个“已知数据”合并到SSDT项目中,或者可以用于事后复制的过程?我已经有了将种子数据加载到系统中的后部署脚本(类型等),所以我可以将所有已知数据放在那里,但这可能是几十个额外的sql文件,可能会管理所以我不是很疯狂

由于已知数据的复杂性和数量,使用位于数据库顶部的应用程序来插入它是不切实际的。

我正在考虑探索bacpac选项,但在此之前想要了解是否有其他方式人们在过去使用已知数据管理功能分支的集成测试。

3 个答案:

答案 0 :(得分:1)

如果我理解正确,您可以复制数据库之间的所有数据,以便执行集成测试。

如果这是正确的,你可以:

  1. 在单独的架构中创建存储过程以填充表。例如,dbo.MyTable将由seed.usp_MyTable或;
  2. 播种
  3. 使用智能命名约定,在单独的数据库中创建存储过程以填充表。
  4. 对于这两个选项,可以使用主存储过程来执行所有种子过程。

    两者的好处是:

    • 所有存储过程都是源控制的,确保了历史记录 捕获测试数据。
    • 以编程方式识别种子数据覆盖非常简单 因为每个表都有一个匹配名称的存储过程。
    • 启动种子过程非常简单 部署,只需包括部署后脚本或SQL任务来执行主种子过程。
    • 种子数据程序可用作额外的回归测试 检查列或数据类型更改时的源漂移。

    每种方法都有利弊:

    1. 所有种子程序都是同一个数据库的一部分 他们引用的表格。这简化了SSDT项目,因为没有 需要外部参考。
    2. 可以针对不同的种子数据进行利用 环境。对数据表项目的外部引用是 需要,但可以为每个项目创建不同的种子项目 环境。

答案 1 :(得分:1)

您可以采取以下几种方法:

  1. 使用备份/快照
  2. 在单独的.sqlproj / dacpac
  3. 中集成测试/测试数据
  4. 将数据设置为测试的一部分
  5. <强> 1。使用备份/快照

    您可以获取处于已知状态的数据库,然后使用备份或快照。我不是很喜欢这个,因为你总是需要保持你的基础是最新的或不时地刷新它。

    <强> 2。在单独的.sqlproj / dacpac

    中集成测试/测试数据

    这是我通常会对单元测试所做的(对我而言,集成测试通常使用调用数据库的应用程序的语言)。

    我的解决方案中有一个单独的.sqlproj,它具有对主项目的“相同数据库”引用。将测试种子数据放入集成测试和Post-Deploy.sql中。

    如果您有多个文件,请使用“:r”导入以包含这些文件,使用“:r”导入以包含主项目的后部署,就像发布时一样,dacpacs引用的没有执行前/后部署脚本。

    如果在部署测试项目和/ p之前没有使用过像这样的引用:IncludeCompositeObject = True

    第3。将数据设置为测试的一部分

    如果您已经拥有一个大型套件,这可能会更难,但我通常会建议,作为每个测试设置的一部分,您将获得的数据处于您认为适合该测试的状态。

    这样就可以阻止任何脆弱性以不同的顺序运行测试等。

    我没有看过bacpac的,这可能是一种有趣的方式来处理它。

答案 2 :(得分:1)

BULK INSERT

到目前为止,我发现获取静态数据进行测试的最快方法是使用post脚本中预先填充的数据文件中的“BULK INSERT”。主要问题是我需要提供BULK INSERT的确切文件路径。但是,您可以使用发布变量。此解决方案是获取数据的最快方法,它比INSERT / MERGE语句执行得更好。

插入/合并

如果没有那么多数据,那么后脚本中的INSERT / MERGE运行良好。已经实现了存储过程,可以帮助生成这些语句。您可以查看on github

<强> tSQLt

这与实际问题没有关系,但我强烈建议使用tSQLt framework进行测试。它不是集成而是单元测试,但如果使用得当,您将不需要预先填充的数据,它将适用于任何数据库。