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

Question

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

我是一名 C# 开发人员(非 DBA)，我们正处于一个全新项目的开发阶段(10 – 15 名开发人员)，我们目前正在定义我们的开发流程，包括处理数据库开发。

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

EF 5(模型优先，也许我们先将其更改为数据库，因为 View 、索引等问题更容易处理)

SSDT(SQL Server 数据工具)

VS 2012/TFS 2012

用于自动化单元/集成测试的 MS 测试

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

每个功能都由一名开发人员在单独的功能分支上开发

设计和实现单元测试(=功能实现)

如果某个功能需要访问数据库，那么开发人员必须
a) 创建/更新 EF 模型
b) 通过 EF 的“从模型生成数据库”创建 localDB 数据库
c) 通过模式比较创建/更新 SSDT 项目
d) 使用测试初始化​​方法创建单元测试，该方法创建新数据库并根据每个测试的测试数据

将功能分支合并回集成分支

checkin 合并后，CI 构建执行单元/集成测试

因此，有些要点我不是 100% 确定如何解决它们(尤其是使用单元测试进行数据库处理)，如果您能让我朝着正确的方向发展，我将不胜感激:

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

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

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

c) 还是手动创建测试数据库并将 *.mdf 文件保存到源代码管理文件夹的根目录并为每个测试创建一个副本？但这我不喜欢，因为开发人员 A 可以覆盖该文件，该文件可能会更改之前 checkin 其更改的另一个开发人员 B。这意味着开发商

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

a) 执行测试特定的 SQL 脚本，为每个测试插入适当的测试数据。我认为这也意味着创建第 1 点中提到的新数据库。这也是我的首选。

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

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

也许最好提及我们对单元测试的期望。我们的单元测试的目标不是像存储过程等那样测试数据库模式。我们想使用“代码”单元测试来测试我们应用程序的部分功能，这些单元测试也可以看作是集成测试。

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

Answer 1

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