私は今、いくつかのフォーラム、ブログ、MSDNなどで日を探していますが、これまでのところこのトピックに関するガイダンスは見つかりませんでした。私はSSDT開発の情報とドキュメントが十分に文書化されておらず、VS 2010データベースプロジェクト（http://vsdatabaseguide.codeplex.com/）のようなベストプラクティスのドキュメントは存在しないと思うので、この投稿をより詳細に説明しようとします。SSDT開発プロセスのヒントと自動ユニット/統合テストに関するベストプラクティス
私はC＃開発者（DBAなし）であり、私たちはグリーンフィールドプロジェクト（開発者10〜15人）の開発段階にあり、現在はデータベース開発の処理を含む開発プロセスを定義しています。
我々が使用する技術とツールチェーンは：
- EF 5（ビュー、インデックスなどのような問題が処理する方がはるかに簡単であるため、モデルは最初、多分私達は、最初にデータベースに変更）
- SSDT（SQL Serverデータツール）
- VS 2012/TFS 2012
- MSのテスト自動化されたユニット/統合テストのための
開発プロセスは、テスト駆動開発に基づくものであり、このようになりますされています
各機能は、個別の機能ブランチ- 機能はデータベースにアクセスする必要があり、開発者は を持っている必要があります。a）EFモデルの作成/更新 b）EFの「モデルからデータベースを生成」を使用してlocalDBデータベースを作成します。 c）スキーマ比較を介してSSDTプロジェクトを作成/新しいデータを作成するテスト初期化メソッドを使用して単体テストを作成するベースと各テスト
は、だから私はないですいくつかのポイントがある
自動化されたユニットテストのためのデータベースの作成を解決する方法：
a）実行されたテストメソッドごとに、SQLデータベース生成スクリプト（SSDT公開機能を使用して以前に手動で作成できます）を実行しますか？これは私が好むオプションです。なぜなら各テストには、各テストがクリーンで一貫性のあるデータベース状態を持っているからです。テストごとにlocaldbデータベースを作成する際にパフォーマンス上の問題はありますか？
b）またはmsbuildタスク "SQLPublish"または "sqlPackage.exe"を使用しますか？これは一度だけの作業であり、単体テストごとに新しいテストデータベースを作成したいので、これはオプションではないと思います。
c）または、手動でテストデータベースを作成し、* .mdfファイルをソースコントロールフォルダのルートに保存し、テストごとにコピーを作成しますか？しかしこれは私が好むのは、開発者Aが以前に自分の変更をチェックした別の開発者Bからの変更を持つファイルを上書きできるからです。
a）は、各テストのための適切なテストデータを挿入するテスト固有のSQLスクリプトを実行します。そして、これは、開発者、自動ユニットテストのためのテストデータの作成を解決する方法
があることを意味します私はこれもポイント1で述べたように新しいデータベースを作成することを意味すると思います。これもまた私の選択肢です。
b）またはEFを使用してテストデータを作成すると、実際には機能ユニットテストによって暗黙的にテストする必要があるEFモデルの実装に依存するため、クリーンな方法ではないようです。
c）または手動で作成したテストデータベースファイルを使用します。しかし、これは開発プロセスをより複雑にするだろう。また、これは他の開発者がチェックインすることによっても無効にすることができます。
私たちのユニットテストの目標をbe.Theするために私たちは私たちのユニットテストに期待言及するかもしれないその良いように、ストアドプロシージャなどのデータベース・スキーマをテストすることはありません。我々は、統合テストと見なすことができる "コード"単体テストを使用して、アプリケーション機能の一部をテストしたいと考えています。
誰もあなたと同様の開発プロセスを持ち、あなたの経験は何ですか？ 開発プロセスを改善するための推奨事項はありますか？ SSDT開発に関するリソースやベストプラクティスのドキュメントはありますか？ 私にとって最も重要な質問は、適切なデータベース処理と統合テストを含む自動化された単体テストをどのように解決しましたか？
純粋なEFモデルを使用するのではなく、まず最初にDBを実行してください。リレーショナルDB内に「オブジェクト指向」のテーブル構造がある可能性は低くなります。 DBが最初から完全に作成するまでの時間は、ロードするデータの量によって異なります。 ＃1の場合、私は "A"に傾いていますが、必要に応じて "Debug"インスタンスを（localdb）から実際のSQL Serverに変更することができます。また、毎回新しいDBを公開することもできます。 "C"は悪い選択です。 ＃2 - 私はここでも "A"の方に傾いています。 TSQLUnitまたは同様のオプションを調べることができます。 –
おそらくこの質問は、programmers.stackexchange.org、またはdba.stackexchange.orgで尋ねる必要があります。しかし、そこにローミングしている眼球は少なくなります。 – knb
私の最初の本能は、データベース専門家を雇うべきだということです。私はデータベースの専門家が自分のアプリケーションを設計することを許しません。アプリケーション開発者にデータベースを設計させるのは無責任です。そして決してEF rtoを使用してデータベースを設計することはありません!!!!!!!!! – HLGEM