ベストプラクティス（ユニット）Windows Azureのテスト

Question

短期間でWindows Azureに基づいてプロジェクトを開始します。そして、私はWindows Azureプロジェクトのテストで何が経験されたのか疑問に思っていました（TFSビルドサーバーでの継続的な統合）？私が思っていた

（TDDを使用して、最終的に）いくつかの点：

• あなたは（あなた自身の書かれたラッパークラスに）モック使用していますか？
• ストレージエミュレータを使用していますか？
• サービスをAzureにデプロイし、ビルドサーバからクラウドにテストを実行しますか？ （費用はどうですか？）

Thnaks in advance！

Answer 1

Windows Azure以外のアプリケーションで単体テストを作成するのと同じ良い方法が適用されます。実際にテストしているものに外部依存関係がある場合は、細かいユニットテストのためにその依存関係を混乱させて注入する必要があります。

例えば、私がWindows Azure Storage Queuesを使用しているとき、私は自分自身と対話するために使用するインターフェイスを持っています。そのため、自分のコードではキューサービスを消費しています。モックを注入するための注入。これにより、単体テスト時に実際にエミュレータに対処する必要がなくなります。ほとんどの場合、キューを扱うコードの実際の具体的な実装は、非常に薄いラッパーではありません。

私は個人的に100％テストカバレッジを撮影しません。そのため、ラッパーの具体的な実装を利用した直接的な単体テストはできません。多くの場合、これらのラッパーを実行し、システムの複数の側面を一緒に処理する統合テストを実行しようとします。いくつかのケースでは、エミュレータで（たとえばストレージ操作のために）統合テストを実行できますが、場合によってはWindows Azure環境（ACSまたはサービスバスの使用の場合）にアクセスするだけで実行する必要があります。

理想的には、Azureで最小限のテストサーバーをスピンアップし、ソリューションを展開し、施設では実行できない統合テストを実行するための一連のスクリプトを用意したいと考えています。それから、その結果を得て、スクリプトをすべて終了させます（または、必要に応じて実行することもできます）。次に、これらのスクリプトを頻繁に使用して問題を検出する統合テストスイートを実行しますが、テスト環境を常に実行していなければ、何かをチェックインするたびに実行する必要はありません。 Azureで実行されている半永久的なテスト環境のコストであれば、削除と再デプロイではなく、少しだけコストを削減するために、スクリプトを更新のデプロイメントにするようにしてください。デプロイが発生します）。

私は、あなたがいくつかの異なる意見を得る可能性が高いので、この質問は非常に主観的なものだと思います。