我现在在几个论坛、博客、MSDN 等上搜索了几天，但到目前为止我还没有找到关于这个主题的任何指导。我将尝试以更详细的方式解释这篇文章，因为我认为 SSDT 开发的信息和文档没有很好的文档记录，并且不存在像 VS 2010 数据库项目 ( http://vsdatabaseguide.codeplex.com/ ) 这样的最佳实践文档。
我是一名 C# 开发人员（没有 DBA），我们正处于一个绿色项目（10 - 15 名开发人员）的开发阶段的开始，我们目前正在定义我们的开发过程，包括处理数据库开发。
我们要使用的技术和工具链：
- EF 5（模型优先，也许我们先将其更改为数据库，因为视图、索引等问题更容易处理）
- SSDT（SQL Server 数据工具）
- VS 2012 / TFS 2012
- 用于自动化单元/集成测试的 MS 测试
开发过程基于测试驱动开发，如下所示：
- 每个功能都由一个开发人员在单独的功能分支上开发
- 设计和实施单元测试（=功能实施）
- 如果某个功能需要数据库访问，则开发人员必须 a) 创建/更新 EF 模型 b) 通过 EF 的“从模型生成数据库”创建 localDB 数据库 c) 通过模式比较创建/更新 SSDT 项目 d) 创建使用创建新数据库并根据每个测试的测试数据的测试初始化方法进行单元测试
- 将功能分支合并回集成分支
- 签入合并后，CI 构建执行单元/集成测试
所以有些点我不是 100% 确定如何解决它们（尤其是使用单元测试处理数据库），如果你能把我引向正确的方向，我将不胜感激：
如何解决自动化单元测试的数据库创建：
a) 为每个执行的测试方法执行 SQL 数据库生成脚本（之前可以通过 SSDT 发布功能手动创建）？这是我更喜欢的选项，因为每个测试都有一个干净且一致的数据库状态。为每个测试创建 localdb 数据库是否存在性能问题？
b) 还是使用 msbuild 任务“SQLPublish”或“sqlPackage.exe”？我认为这不是一个选择，因为这将是一次性的事情，我想为每个单元测试创建一个新的测试数据库。
c) 还是手动创建测试数据库并将 *.mdf 文件保存到源代码管理文件夹的根目录并为每个测试创建一个副本？但我不喜欢这样，因为开发人员 A 可以覆盖该文件，该文件可能具有来自之前签入他的更改的另一个开发人员 B 的更改。这意味着开发商
如何解决自动化单元测试的测试数据创建问题：
a) 执行测试特定的 SQL 脚本，为每个测试插入适当的测试数据。我认为这也意味着创建一个新数据库，如第 1 点所述。这也是我的首选。
b) 或者使用 EF 创建测试数据似乎不是一种干净的方法，因为这取决于 EF 模型实现，实际上应该通过功能单元测试隐式测试。
c) 或使用手动创建的测试数据库文件。但这会使开发人员的开发过程更加复杂。这也可能被其他开发人员签入覆盖。
也许值得一提的是我们对单元测试的期望。我们单元测试的目标不是像存储过程等那样测试数据库模式。我们希望使用“代码”单元测试来测试我们应用程序的部分功能，这也可以看作是集成测试。
那么你们中的任何人都有类似的开发过程吗？你们的经验是什么？有什么建议可以改进我们的开发流程吗？是否有任何关于 SSDT 开发的资源或最佳实践文档？对我来说最重要的问题是，你是如何解决自动化单元测试的，包括正确的数据库处理和集成测试？