SSDT 项目和使用已知数据管理集成测试

Question

我正在迁移到 SSDT，以便对带有附带数据库的大型项目的数据库结构进行模式控制。该项目内部已经有数百个处于各种脆弱状态的集成测试。其中许多使用我称之为“已知数据”的东西来执行集成测试。测试依靠这些数据才能成功运行。

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

使用 SSDT，有没有办法将这些“已知数据”合并到 SSDT 项目或可用于事后复制的进程中？我已经有将种子数据加载到系统中的部署后脚本（类型等），所以我可以将所有已知数据放在那里，但这可能是几十个额外的 sql 文件可能需要管理，所以我并不喜欢它.

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

我正在考虑探索一个 bacpac 选项，但在此之前，我想看看人们过去是否有任何其他方法可以使用已知数据管理功能分支的集成测试。

Answer 1

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

1. 使用备份/快照
2. 在单独的 .sqlproj/dacpac 中进行集成测试/测试数据
3. 将数据设置为测试的一部分

1.使用备份/快照

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

2。在单独的 .sqlproj/dacpac 中进行集成测试/测试数据

这是我通常会为单元测试做的事情（对我来说，集成测试通常使用调用数据库的应用程序的语言）。

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

如果您有多个文件，请使用“:r”导入来包含这些文件，也使用“:r”导入来包含来自主项目的后期部署，因为发布发生时，dacpacs被引用的没有执行其部署前/部署后脚本。

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

3.设置数据作为测试的一部分

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

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

我还没有看过 bacpac 的这个，这可能也是一种有趣的处理方式。

Answer 2

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

如果正确，您可以：

1. 在单独的架构中创建存储过程以填充您的表。例如 dbo.MyTable 将由 seed.usp_MyTable 播种，或者；
2. 在单独的数据库中创建存储过程以填充表，同样使用智能命名约定。

对于这两个选项，主存储过程可用于执行所有种子过程。

两者的好处是：

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

每种方法各有利弊：

1. 所有种子过程都是与 他们引用的表格。这将 SSDT 项目简化为没有 需要外部参考。
2. 不同的种子数据可以用于不同的 环境。对数据表项目的外部引用是 需要，但可以为每个创建不同的种子项目 环境。

Answer 3

批量插入

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

插入/合并

如果没有那么多数据，那么在 post 脚本中插入/合并效果很好。已经实现了可以帮助生成这些语句的存储过程。您可以查看on github。

tSQLt

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