Windows Phoneでの単体テスト中のコードカバレッジ制御

ごあいさつhabrazhitel！
Windows Phoneでのアプリケーションの単体テスト中にコードカバレッジの制御を確立したことで、私の成果を共有したいと思います。 この問題を解決する際に、「正しい」アプリケーション設計のいくつかの側面に対処しなければならなかったことは注目に値します。 したがって、この投稿は小さな教科書と見なすことができます。

問題の声明

与えられた：
Windows Phone用の小さなアプリケーションの開発が始まります。 アプリケーションは典型的なものです-サーバーからデータを取得し、何らかの形でユーザーに表示します。
必須です：
アプリケーションのアーキテクチャを設計して、継続的な統合により、作業のロジックを担当するアプリケーションの最大コードが、このカバレッジを制御する機能を備えたテストによって閉じられるようにします。

一般的なアプローチ

すでに書いたように、Windows Phoneランタイムにはコードカバレッジを制御する手段がありませんでした。 Naggとhalkarのアドバイスで、Portable Class Libraryのアプリケーションの機能（ロジック）でコードをレンダリングしました。 これにより、カバレッジ制御を備えた標準の.NET Framework環境でテストを実行できました。 さらに、このアプローチは、継続的インテグレーションのシステムでシャーマニズムを排除し、テストの実行時間も短縮します。

したがって、簡単な方法で、アプリケーションは3つのコンポーネントの形式で表すことができます。

すべてのアプリケーションロジックは、Windows Phoneランタイムまたはテスト環境に依存しないPCLにあります。
Windows Phoneアプリケーションはこのライブラリを使用し、XAMLマークアップと最小限のコードを含みます。
テストDLLはPCLも参照し、実際のテストコードが含まれています。 MSTestをテストフレームワークとして使用しましたが、問題ではありません。

アプリケーションロジックは真空で動作することはできません。WebサーバーやWindows Phoneに直接接続されている他のユーザーとユーザーと対話する必要があります。 同時に、テストを実行する場合、この相互作用は通常の.NET Frameworkの環境で既に何らかの方法でエミュレートされる必要があります。
その結果、PCLから以下が発行されました。

• Webサーバーでの作業（要求の送信と応答の受信）
• ファイルの操作（保存、読み取り、リストの取得）
• 文字列リソースのローカライズ
• インターネット接続の可用性を確認する
• 他の何か

これについてもう少し検討してください。 アプリケーションの一般化されたスキームは次のようになります。

1. HTTP要求がサーバーに送信されます
2. 回答が受け入れられました
3. 回答の解析/処理
4. 分解結果が表示されます。

テストするロジックはステージ3のみです。この場合、他のすべてのステージを担当するコードをPCLから削除することは論理的です。
Windows Phoneの画面に表示する場合、このような削除は非常に透過的です。ViewModelsはPCLにあり、ViewModelsへのコントロールのバインドプロパティはXAMLで説明されています。 テスト中に、ViewModelの必要なプロパティとメソッドをプルし、ユーザーアクションをシミュレートし、それらに対する反応をチェックするだけです。

次に、サーバーの操作を検討します。 PCLにはHTTPクライアント実装（ HttpWebRequest ）があり、PCLでWebサーバーコードを直接記述することは論理的に思えます。
ただし、アプリケーションのロジックをテストすることが目標であることを忘れてはなりません。 Webサーバーへの要求をPCLに送信するためのコードをしっかりと縫う場合、テストのために、サーバーをシミュレートして別のWebサーバーを上げるか、何らかの方法で要求をインターセプトする必要があります。

続けましょう。 処理中に、データをキャッシュすることができます-デバイス上のファイルとして保存されます。 ただし、PCLには完全なファイル管理ツールがありません。 これは、異なるランタイムが異なるストレージ編成メカニズムを使用するという事実によるものです。 したがって、使い慣れた.NETでは「通常の」ファイル（たとえば、 File ）であり、Windows PhoneではIsolatedStorageFileです。 また、テスト中にこのようなリポジトリをシミュレートする必要があることを忘れないでください。

実際の分離は簡単な方法で行われました。PCLでは、Webリクエスト、ファイル、ローカライズなどを操作するためのインターフェイスを宣言し、独自の仕様でWindows Phoneアプリケーションに既に実装しています。 したがって、テスト目的では、「ライブ」環境の作業を多少なりとも確実にシミュレートするような方法でこれらのインターフェイスを実装する必要もあります。

制御の反転

ある程度の近似では、この否定は制御の科学的逆転と呼ばれます。 私自身はネットワーク内のこのトピックに関する十分な資料を知らないため、ジャングルには入りません 。主なポイントのみを説明します。 意味のゆがみの可能性があることをグルに事前に謝罪します-突然の場合は、コメントを待っています。

たとえば、ファイルインターフェイスを見てみましょう。

  public interface IFileStorage { Stream GetWriteFileStream(string fileName); Stream GetReadFileStream(string fileName); bool IsFileExists(string fileName); List<string> GetAllFileNames(string path); } 

このインターフェイスは、ストレージの詳細に入らずにファイルを操作するのに十分です。 したがって、これ以上何も知らないのは、このインターフェースとPCLについてです。 Windows Phoneアプリケーションに実装され、実装はIsolatedStorageFile使用します。
このインターフェイスはテストDLLにも実装されており、非常にプリミティブです。すべてのファイルは、 Dictionary<string, MemoryStream>形式でメモリに保存されます。 したがって、プログラムのロジックは、実際のファイルで機能すると考えて満足しています。また、テストの独立性の問題を解決しているので満足しています。 新しいテスト-クラスの新しいインスタンス-クリーンな「ファイルシステム」。

ただし、ファイルに加えて、Web、ローカリゼーションなどと作業を切り離す必要があります。 便宜上、これらすべてを別のインターフェイスで組み合わせます。

  public interface IContainer { IFileStorage FileStorage { get; } IDataRequest DataRequest { get; } ILocalizer Localizer { get; } IUiExtenter Extender { get; } DateTime Now { get; } } 

私はそれを「コンテナ」と呼びましたが、「制御の反転」テンプレートの用語では、これは完全に正しいとは限りません。
このインターフェイスは、ファイル（ FileStorage ）、サーバーリクエスト（ DataRequest ）、ローカリゼーション（ Localizer ）およびその他（ Extender ）を操作するためのPCLロジックツールを提供し、簡潔にするために1つのインターフェイスに統合されています。
それとは別に、Nowプロパティに注目します。 テスト専用です。 実際のところ、多くの場所でロジックは現在の時刻に関連付けられており、テスト環境を正しくエミュレーションするには、この時刻を変更する必要があります。 システム時刻を変更するのは悪い考えです。このため、このプロパティが表示されます。 主なことは、 DateTime.Now代わりにこのプロパティを使用する必要があることを思い出すことでした。
コンテナには、Windows PhoneアプリケーションとテストDLLの2つの実装があります。 各コンテナは、そのインターフェイス実装を「スリップ」しました。 そのため、テストDLLのコンテナはIDataRequestをスタブの形式で実装し、テストでサーバーの応答と通信の問題をシミュレートできるようにしました。
IContainerを実装するオブジェクトは、アプリケーションの最初に作成されます。 テスト中に、テストごとにそのような新しいオブジェクトが作成されます。 アプリケーションロジックを管理するクラスには、このオブジェクトへの参照が必要です。 これを行う簡単な方法は、すべてのクラスのコンストラクターにリンクを要求することです。
もちろん、 Unity Application Blockなど、制御スキームの反転を実装するための既製のバイクが多数ありますが、主に教育目的でこのオプションを選択しました。 もちろん、「アダルト」プロジェクトでは、既成のソリューションを使用することをお勧めします。

問題

理論的にはすべてが美しく美しく聞こえますが、実際にはいくつかの問題に直面しなければなりませんでした。 厳密に言えば、PCLですべてのロジックを作成することはできませんでした。 そのため、ページ間のナビゲーション、Dependencyプロパティを作成するためのコード、およびその他のいくつかは、Windows Phoneアプリケーションプロジェクトに残っていたため、クローズドテストではありませんでした。 理論的には、このコードの大部分をPCLに転送できますが、これにより、抽象化の不当な（もちろんIMHO）肥大化が起こり、結果として将来のコードのサポートが複雑になります。
別の問題は、XAMLのプロパティを制御するためのViewModelsプロパティのバインドです。 後者の多くには、PCLでは使用できない特定のタイプ（ Brush 、 Visibility ）があります。 この問題は変換メカニズムによって美しく解決されますが、多数のコントロールを使用すると、このような変換によってアプリケーションの速度が大幅に低下する可能性があることを覚えておく必要があります。

もう一つ

私には、より正確に実装できるように思われるものがいくつかありますが、その方法はわかりません。 正しい道を設定してくださった方々に感謝します。
最初のこと。 システムのロジックに従って、アルゴリズムの特定の場所で、ユーザーに選択肢のあるダイアログを表示し、ユーザーの選択に応じてアルゴリズムを続行する必要があります。 コンテナインターフェイスの1つにShowDialogメソッドを実装し、PCLのコードから直接呼び出すことほど良いものは思いつきませんでした。 したがって、このメソッドの「戦闘」実装では実際のダイアログが表示され、ユーザーの選択を待っていましたが、テストでは事前に設定された値が返されました。
第二に。 このロジックは、タイマーコントロールの状態を更新します。 ただし、PCLで使用可能なTimerクラスは、別のスレッドで間隔終了ハンドラーを呼び出します。 この場合、要素の状態を更新しようとすると失敗します。 私の頭の上の解決策は、引数としてデリゲートを持つメソッドをインターフェイスに記述することです。 「戦闘」実装では、このメソッドはBeginInvokeを呼び出してメインスレッドとテストで同期します-単にデリゲートを呼び出します。
手が届かないまで怠けていたもう1つのことは、テスト環境で同じタイマーをエミュレートすることです。 現在、いくつかのテストで強制的な遅延が発生していますが、これは見苦しいものです。

まとめ

残りのテストでは、ほとんどの機能が閉じられました。 ViewModelsテストコードは、実際のテストケースの説明に似ています（「ここをクリック」-「ここにそのような番号を入力」-「値を期待値と比較」）。
そのようなテストを書くことは、開発者を志すテスターをやる気にさせる良い方法です。 そして、彼らはクリックする代わりにコードを書いて喜んでいて、テストが進行中です:)

スクリプトとバグを含むアイデアがなくなったとき、TeamCityの緑色の目で、戦闘中に火星にアプリケーションを直接起動できるという自信だけがありました。 そして、いくつかのチップを「固定」する必要があるときにテストが問題をキャッチした回数-統計の構築のみが知っている...

最も重要な結果は、コードの実行後、テストが「合格」した行と変更されていない行を確認できることです。 このデータは、統計の形式（「影響を受ける」クラス、メソッド、および詳細レベルの異なるコード行）の両方、および赤と緑の色付きのソースコードの形式で表示されます。

すべてのコードテストを閉じることができませんでした。 したがって、コンテナインターフェイスの実装と同様に、分離コードは定義により閉じられずに残ります。 ただし、PCL内にあったもの（およびこれは、その機能に直接関与するプログラムコードのほとんどです）は、非常によくカバーされ、制御されています。

私はマニアなので、メソッドのカバレッジが100％未満の場合（テストが入力されなかったラムダ式など、制御されたコードに少なくとも1つのメソッドがあった場合）、ビルドを「フォール」に設定します。 普通の人にとっては、このような制御はおそらく多すぎるでしょう。
いずれにせよ、コードカバレッジはテストによる機能的カバレッジと相関しており、赤い線の研究はしばしば、エンコードすべきテストシナリオについての考えを促しました。

主な結論は、Windows Phoneの場合、コードカバレッジ制御を使用して単体テストを整理できるということです。
カバレッジメトリックを正式に使用することは、もちろん無意味です。 ただし、これは他のメトリックの正式な使用に適用されます。 しかし、コーティングを手間のかかるKPIとしてではなく、品質を改善するためのツールとして考える場合、これは非常に強力なことです。