5

かなり複雑だが MVC を利用するアプリケーションをレトロスペクティブに単体テストしようとしています。レトロスペクティブに単体テストを適用するのは理想的ではないことはわかっていますが、既存のコードをリファクタリングすることで可能だと信じています。ほとんどの場合、他のユニットに依存せずに 1 つのユニットを単体テストすることはできません。つまり、ビューはモデルに依存しています。

この場合、単体テストを行う最良の方法は何ですか? 実機を流用するのと模擬モデルを作るのとではどちらが良いでしょうか？

私の状況で実際のモデルを利用する際の問題は、モデルが XML からデータを取得する他の応答クラスに依存しているため、依存の連鎖が生じることです。このモデルには多くのデータがあるため、これを使用する方がはるかに簡単ですが、要点を見逃している可能性があります。

簡潔にするために、アプリケーションの UML を提供しました。

ここに画像の説明を入力

**編集 ****

私が正しければ、モッククラス内にモックデータを作成するのがベストプラクティスですか? たとえば、ビュー クラス「PlaylistPanel」をエラーなしで実行するために必要なデータを作成するモック クラス「MockPlaylistPanelModel」があります。

class MockPlaylistPanelModel extends Mock implements IPlaylistPanelModel
{
  /** 
   * Return all playlist items
   * @public 
   */
  public function get mainPlaylistItems():Vector.<PlaylistData> 
  {
    var playData:Vector.<PlaylistData> = new Vector.<PlaylistData>;
    var playlistResp:PlaylistData = new PlaylistData(0, "", "", 0, 0, 0, 0);
    playData.push(playlistResp);
    return playData;
   }

}
4

3 に答える 3

6

単体テストを既存のアプリケーションにレトロスペクティブに適合させるには、多くの場合、単体テストをサポートするようにアプリケーション コードを変更する必要があります (リファクタリングを実行する必要があるかもしれないと正しく述べているように)。ただし、もちろん、ここでのリスクは、アプリケーションの変更によってバグが発生することです。これは、いくつかのテストを行わないと保護できません。

したがって、賢明なアプローチは、いくつかの主要なユース ケースをカバーするシステム レベルのテストを実施することです。これは、アプリケーションの周りに一種の「テストの足場」として機能します。つまり、アプリケーションをよりテストしやすくするために変更する際に、バグが発生するリスクを減らしながら、より安全に低レベルのテストを導入し始めることができます。これが整ったら、開発者はコードを変更する前に、コードを変更する前にテストを作成する必要があるというポリシーを導入できます。これにより、アプリケーションの周りに一連の自動化されたテストを有機的に成長させることができます。

レガシー コードを効果的に使用することを強くお勧めします。この優れた本には、自動化されたテストがほとんどない既存のアプリケーションにテストを導入するためのあらゆる種類の便利なテクニックが網羅されています。

テスト用にモック クラス内にモック データを作成する必要があるかどうかについての質問に関して、これはオブジェクトのテスト バージョンを注入するときに使用できる 1 つのアプローチですが、おそらく最善ではありません。Mockitoのようなモッキング フレームワークを使用すると、動作が明確に定義されたモック オブジェクトをその場で簡単に作成できます。あなたの場合、Mockito を使用してモック モデルの実装を作成し、モック モデルに依存するオブジェクトにモック モデルを挿入できます。

于 2013-07-19T11:13:28.610 に答える
0

それらは単体テストではありません。それらは統合テストです。

はい、モックを使用して単体テスト用のクラスを分離します。

于 2013-07-19T09:41:53.997 に答える