当有多人在一个项目上工作时,所有人都可以更改数据库架构,那么最简单的单元测试/测试/验证方法是什么?目前我们得到的主要建议是为每个表编写测试来验证列名、约束等。
是否还有其他人做过类似的/更简单的事情?我们正在使用C#和SQL Server,如果这会有任何实际差别。
更新:
- 我们正在使用SSIS包进行大部分工作,因此可以很少编写针对C#代码的单元测试。
- 创建表/存储过程的代码分布在SQL文件中。由于构建系统,我们可以维护单独的VS DB项目文件,但我不确定这如何帮助我们验证模式。
当有多人在一个项目上工作时,所有人都可以更改数据库架构,那么最简单的单元测试/测试/验证方法是什么?目前我们得到的主要建议是为每个表编写测试来验证列名、约束等。
是否还有其他人做过类似的/更简单的事情?我们正在使用C#和SQL Server,如果这会有任何实际差别。
更新:
可能的解决方案之一是使用面向数据库开发人员的Visual Studio,并将模式与其余代码一起存储在源代码控制中。这样可以查看差异,并获得更改者的历史记录。
或者,您可以使用SQLCompare等工具来查看一个数据库相对于另一个数据库所做的修改。
这是否应该被视为单元测试或集成测试还有待商榷。基于我不想在每次迭代代码时运行旧测试的事实,我倾向于将其视为集成测试。无论你想如何称呼它,我发现它是那种情况下一个有用的工具。
这是一个有趣的问题!有很多工具可以用来测试存储过程,但没有专门用于测试数据库模式的工具。
你不觉得为代码编写的单元测试通常会发现数据库模式中的任何问题吗?
我使用的一种方法是编写存储过程,将测试数据从开发人员的模式复制到测试模式。这种方法比较粗糙,因为当存储过程遇到模式之间的任何差异时,它们通常会崩溃,但它确实会提醒您有关未告知您的任何更改。
并且指定某人作为数据库管理员,监控模式的更改?
你不觉得为代码编写的单元测试通常会发现数据库架构中出现的任何问题吗?
当然了,这是基于你的测试覆盖面足够全面的前提下。
这并不完全符合单元测试的范式。我建议对模式进行版本控制,并将写入访问权限限制为单个合格的团队成员,例如DBA或团队负责人,他们可以根据整个应用程序验证任何请求的更改。模式更改不应该随意进行。