logo标签列表

你如何进行（单元）测试数据库架构？

c#.netsql-serverunit-testingtesting
12

当有多人在一个项目上工作时，所有人都可以更改数据库架构，那么最简单的单元测试/测试/验证方法是什么？目前我们得到的主要建议是为每个表编写测试来验证列名、约束等。

是否还有其他人做过类似的/更简单的事情？我们正在使用C#和SQL Server，如果这会有任何实际差别。

更新：

  • 我们正在使用SSIS包进行大部分工作，因此可以很少编写针对C#代码的单元测试。
  • 创建表/存储过程的代码分布在SQL文件中。由于构建系统，我们可以维护单独的VS DB项目文件，但我不确定这如何帮助我们验证模式。
7个回答
4

可能的解决方案之一是使用面向数据库开发人员的Visual Studio，并将模式与其余代码一起存储在源代码控制中。这样可以查看差异，并获得更改者的历史记录。

或者，您可以使用SQLCompare等工具来查看一个数据库相对于另一个数据库所做的修改。

2
您的（关系型）数据库在我看来有两个作用：1）存储数据和2）存储数据之间的关系。
存储数据不是一种行为，因此您不需要对其进行测试。
而要确保关系，请使用约束。大量的约束。随处可见。
哎呀，我忍不住要评论一下：“持有数据不是一种行为，因此您不应该测试它” <= 如果您认为测试它有价值，那么无论理论如何，您都应该测试它。“而且为了确保关系，只需使用约束。到处都是很多约束。” <= 对于大型表/数据库，现实世界通常禁止极端使用约束，因为性能可能会受到影响。同样 - 在现实世界中，编写测试代码可能是唯一的真正选择。这只是我的五分钱。 - Stephan Møller
1
十年后了，是吗？所以我完全同意，如果测试某些东西有价值，那么你应该测试它们。但是，“单元”在“单元测试”中的定义是基于行为的——即单个业务逻辑部分，如果更改它将会发生原子性变化。非行为测试可能很有用，但它们不是单元测试。实际上，问题似乎根本不是关于单元测试，而是关于对任何模式更改进行批准的问题。回想起来，像将DDL输出到文本并在其上运行ApprovalTests这样的事情可能是个好主意。 - George Mauer
1
我知道你的评论是来自09年。但我一直在研究进化数据库设计，并测试模式实际上很常见。在我的情况下，更改模式是迁移脚本的一种行为，我希望有一个检查来确保迁移完成。这样可以让我们快速转换模式并同时进行测试。 - David Price
1
这是一个旧问题，但似乎人们仍然在此处着陆。目前我发现最好的工具是 Red Gate 的 "SQL Test"。它允许您创建作为事务运行的脚本，从而可以运行“沙盒”查询以检查数据库状态。
1
我以前也做过这种事情，虽然不是用C#。首先，我建立了一个基于Ode to Code (page 1 of 5)的模式迁移工具（也有现成的类似工具可用）。重要的是，我所建立的迁移工具允许您指定应用更改的数据库和要应用的版本。然后，遵循测试优先方法，每当我需要进行模式更改时，我都会编写一个测试脚本，该脚本将创建一个测试数据库，在目标更改脚本之前应用版本更改，添加一些数据，在测试下的更改脚本，并确认数据处于预期状态。
我的主要目标是确认在模式迁移期间没有丢失或损坏数据，而不是特别检查模式是否处于特定状态。需要对生产数据集有良好的认识，以便为测试编写代表性样本数据。

这是否应该被视为单元测试或集成测试还有待商榷。基于我不想在每次迭代代码时运行旧测试的事实，我倾向于将其视为集成测试。无论你想如何称呼它，我发现它是那种情况下一个有用的工具。

1

这是一个有趣的问题！有很多工具可以用来测试存储过程，但没有专门用于测试数据库模式的工具。

你不觉得为代码编写的单元测试通常会发现数据库模式中的任何问题吗？

我使用的一种方法是编写存储过程，将测试数据从开发人员的模式复制到测试模式。这种方法比较粗糙，因为当存储过程遇到模式之间的任何差异时，它们通常会崩溃，但它确实会提醒您有关未告知您的任何更改。

并且指定某人作为数据库管理员，监控模式的更改？

0

你不觉得为代码编写的单元测试通常会发现数据库架构中出现的任何问题吗？

当然了，这是基于你的测试覆盖面足够全面的前提下。

0

这并不完全符合单元测试的范式。我建议对模式进行版本控制，并将写入访问权限限制为单个合格的团队成员，例如DBA或团队负责人，他们可以根据整个应用程序验证任何请求的更改。模式更改不应该随意进行。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接