短期間のうちに、Windows Azure に基づくプロジェクトを開始する予定です。また、(TFS ビルド サーバーとの継続的な統合で) Windows Azure プロジェクトのテストの経験はどのようなものでしょうか? (最終的にTDDを使用)
私が疑問に思っていたいくつかのこと：
事前にサンクス！
Windows Azure の外部にあるアプリケーションの単体テストを作成する場合と同じグッド プラクティスが適用されます。実際にテストしているものに外部依存関係がある場合は、その依存関係をモックして、詳細な単体テスト用に注入する必要があります。
たとえば、Windows Azure ストレージ キューを使用している場合、キュー自体と対話するために使用するインターフェイスを使用するため、キュー サービスを使用するコードで、インターフェイスを使用してサブシステムをモックし、依存性注入を使用して、モック。これにより、単体テスト中にエミュレーターを実際に扱う必要がなくなります。ほとんどの場合、キューを操作するコードの実際の具体的な実装は、非常に薄いラッパー以上のものではありません。
個人的には 100% のテスト カバレッジを目指しているわけではないので、ラッパーの具体的な実装を利用した直接の単体テストは行わない可能性があります。多くの場合、これらのラッパーを実行し、システムの複数の側面を連携して実行する統合テストを作成しようとします。エミュレーターで統合テストを実行できる場合 (ストレージ操作など) もありますが、Windows Azure 環境にアクセスして実行する必要がある場合もあります (ACS やサービス バスを使用する場合)。
理想的には、Azure で最小セットのテスト サーバーをスピンアップし、ソリューションを展開し、オンプレミスでは実行できない統合テストを実行するために実行できる一連のスクリプトが必要です。次に、その結果を取得し、スクリプトにすべてをシャットダウンさせます (必要に応じて、オプションで実行したままにします)。次に、問題を検出するのに十分な頻度でこれらのスクリプトを使用する統合テスト スイートを実行しますが、常にテスト環境を実行することに満足しない限り、何かをチェックインするたびにそれらを実行する必要はありません。Azure で実行される半永久的なテスト環境のコストに問題がない場合は、スクリプトを削除して再デプロイするのではなく、更新のデプロイに使用して、コストを少し削減してください (節約は、デプロイが発生します)。
いくつかの異なる意見を得る可能性が高いため、この質問は非常に主観的なものだと思います。