关于SSDT开发过程的提示以及有关自动化单元/集成测试的最佳实践

Question

我现在正在几个论坛,博客,MSDN等上搜索几天,但到目前为止我还没有找到关于这个主题的任何指导.我将尝试以更详细的方式解释这篇文章,因为我认为SSDT开发的信息和文档没有很好地记录,并且没有像VS 2010数据库项目(http://vsdatabaseguide.codeplex.com/)那样的最佳实践文档.

我是一名C#开发人员(没有DBA),我们正处于绿色领域项目开发阶段(10-15名开发人员),我们目前正在定义我们的开发过程,包括数据库开发的处理.

我们想要使用的技术和工具链:

• EF 5(模型第一,也许我们首先将其更改为数据库,因为视图,索引等问题更容易处理)
• SSDT(SQL Server数据工具)
• VS 2012/TFS 2012
• 用于自动化单元/集成测试的MS测试

开发过程基于测试驱动开发,如下所示:

1. 每个功能都由一个开发人员在一个单独的功能分支上开发
2. 设计和实现单元测试(=功能实现)
3. 如果某个功能需要数据库访问,那么开发人员必须a)创建/更新EF模型b)通过EF的"从模型生成数据库"创建localDB数据库c)通过模式比较创建/更新SSDT项目d)创建使用测试初始化​​方法进行单元测试,该方法创建新数据库并根据每个测试的测试数据
4. 将功能分支合并回集成分支
5. 在检入合并后,CI构建执行单元/集成测试

所以有一些观点我不是100%肯定如何解决它们(特别是单元测试的数据库处理),如果你能把我放在正确的方向,我将不胜感激:

1. 如何解决自动化单元测试的数据库创建:

   a)为每个执行的测试方法执行SQL数据库生成脚本(可以通过SSDT发布功能手动创建)？这是我更喜欢的选项,因为每个测试都有一个干净且一致的数据库状态.是否存在为每个测试创建localdb数据库的性能问题？

   b)或者使用msbuild任务"SQLPublish"或"sqlPackage.exe"？我认为这不是一个选择,因为这将是一次性的事情,我想为每个单元测试创​​建一个新的测试数据库.

   c)或者手动创建测试数据库并将*.mdf文件保存到源控制文件夹的根目录并为每个测试创建一个副本？但是我不喜欢这样,因为开发人员A可以覆盖该文件,该文件可能会从之前检查过其更改的其他开发人员B进行更改.这意味着开发人员

2. 如何解决自动化单元测试的测试数据创建:

   a)执行测试特定的SQL脚本,为每个测试插入适当的测试数据.我认为这也意味着要创建一个新的数据库,如第1点所述.再次,这是我的首选.

   b)或者使用EF来创建测试数据似乎不是一种干净的方式,因为这取决于EF模型实现,它应该通过功能单元测试实际上进行隐式测试.

   c)或使用手动创建的测试数据库文件.但这会使开发过程中的开发过程更加复杂.其他开发人员也可以覆盖这一点.

也许很高兴提到我们对单元测试的期望.我们的单元测试的目标不是像存储过程那样测试数据库模式等等.我们希望使用"代码"单元测试来测试部分应用程序功能,这些单元测试也可以看作是集成测试.

那么你们中的任何人都有类似的开发过程,你们的经历是什么？有什么建议可以改善我们的开发过程 有关于SSDT开发的资源或最佳实践文档吗？对我来说最重要的问题是,您是如何解决自动化单元测试的,包括正确的数据库处理和集成测试？

Answer 1

当您需要数据库时，它不是单元测试。对于与实体框架结合的单元测试，您应该使用伪造的 dbcontext。