如果有很多人在处理项目,所有人都可以改变数据库架构,那么最简单的单元测试/测试/验证方法是什么?我们到目前为止的主要建议是为每个表编写测试以验证列名,约束等。
还有其他人做过类似/更简单的事吗?我们正在使用C#和SQL Server,如果这有任何真正的区别。
更新
答案 0 :(得分:4)
一个可能的答案是使用Visual Studio for Database开发人员,并使用其余代码将架构保持在源代码管理中。这使您可以看到差异,并获得谁改变了什么的历史。
或者,您可以使用SQLCompare之类的工具来查看在一个数据库中修改的内容与另一个数据库相比。
答案 1 :(得分:2)
就我而言,你的(关系型)数据库做了两件事:1)保持数据和2)保持数据之间的关系。
保留数据不是一种行为,因此您不会对其进行测试
为了确保关系,只需使用约束。很多限制。到处都是。
答案 2 :(得分:1)
这是一个古老的问题,但看来人们仍然在这里着陆。因此,到目前为止,我发现的最好的工具是Red Gate的“ SQL Test”。它允许您创建作为事务运行的脚本。允许您运行“沙盒”查询来检查数据库状态。
答案 3 :(得分:0)
这是一个有趣的问题!有许多工具可用于测试存储过程,但不用于测试数据库模式。
您是否发现为代码编写的单元测试通常会发现数据库模式有任何问题?
我使用的一种方法是编写存储过程,将测试数据从开发人员的模式复制到测试模式。这是非常粗略和准备好的,因为存储过程通常会在遇到模式之间的任何差异时崩溃,但它会提醒您没有被告知的任何更改。
并提名某人成为监控模式更改的DBA?
答案 4 :(得分:0)
这并不适合单元测试范例。我建议控制模式的版本,并限制对单个合格团队成员(例如DBA或团队负责人)的写访问权限,他们可以针对整个应用程序验证任何请求的更改。架构更改不应随意进行。
答案 5 :(得分:0)
您是否发现为代码编写的单元测试通常会发现数据库模式有任何问题?
当然,这假设您的测试会测试所有内容。
答案 6 :(得分:0)
我以前必须做这种事情,尽管不是在C#中。首先,我基于Ode to Code (page 1 of 5)的讨论构建了一个模式迁移工具(还有现有的工具可以做类似的事情)。重要的是,我构建的迁移工具允许您指定要应用更改的数据库以及要应用的版本。然后,按照测试第一种方法,每当我需要进行模式更改时,我会编写一个测试脚本来创建测试数据库,将版本更改应用到我的目标更改脚本之前,添加一些数据,应用更改脚本测试,并确认数据处于预期状态。
我的主要目标是确认在架构迁移期间没有数据丢失或损坏,而不是特别检查架构是否处于特定状态。需要很好地了解您的生产数据集,因此您可以为测试编写代表性的样本数据。
如果将其视为单元测试或集成测试,则值得商榷。我倾向于考虑它集成测试,基于我不想每次迭代我的代码时都运行旧测试的事实。无论你想要什么,我发现它是一种有用的工具。