4

コードベース全体に拡張され、ある種の( ) に登録されてManagerいる を処理する を作成しました。SuperClassSuperClassManagerSCM

Managerここで、 のみを認識しているmy をテストしたいと思いSuperClassます。SCMただし、サードパーティのライブラリに依存する具体的な を作成しようとしたため、jUnit テストでそれを行うことができませんでした。オプションは、 this のすべてのインスタンスをモックすることSCMです。

今まではすべて問題ありませんでしたが、Managerを処理すると、知らない、または気にしていないSCMの子が返されます。それにもかかわらず、これらの子供たちの身元は、私のテスト (平等など)にとって不可欠です。SuperClassManager

具体的な を使用できないため、SCMの適切な関数への呼び出しの結果をモックする必要がありますがSCM、これは、テストと (間接的に)Managerの子を知り、気にする必要があることを意味しSuperClassます。

コード ベースを確認すると、テストに適した場所がないようです (適切な実際の依存関係が既に維持されています)。

単体テストのために不要な依存関係を導入する価値はありますか?

2012 年 12 月 18 日更新

ここに私の問題の簡略版があります：

package some.package.declaration;

import some.open.source.framework.TopComponent;
import some.open.source.framework.WindowManager;

/**
 * Own source code.
 * Knows WindowManager and TopComponent; but no
 * direct child of TopComponent.
 */
class TopComponentManager{

  /**
   *
   */
  void efficientlyDoOperationsOnCurrentTopComponents(){
    Set<TopComponent> currentTopComponents = get all current TopComponents from WindowManager;
    Set<TopComponent> getNeededTopComponents(currentTopComponents);
    do some operations on the current TopComponents;
    ...
    ...
  }

  void Set<TopComponent> getNeededTopComponents(Set<TopComponent> givenTopComponents){
    Set<TopComponent> neededTopComponents = new HashSet<TopComponent>(givenTopComponents);
    disregard and keep some TopComponents based on controls;
    return neededTopComponents;
  }

}

package some.package.declaration.test;   // same project as TopComponentManager

import jmockit;
import some.open.source.framework.TopComponent;
import some.open.source.framework.WindowManager;

import own.source.code.childrenOfTopComponent.ChildTopComponent;  // Don't want to; need to introduce package dependencies
import own.source.code.childrenOfTopComponent.AnotherChildTopComponent;  // Don't want to; need to introduce package dependencies

class TopComponentManagerTest{

  @Tested
  TopComponentManager _topComponentManager;
  @Mocked
  WindowManager _windowManager;
  @Mocked
  ChildTopComponent _childTopComponent1;  //extends TopComponent; unknown to both TopComponentManager and TopComponentManagerTest
  @Mocked
  AnotherChildTopComponent _childTopComponent2;  //extends TopComponent; unknown to both TopComponentManager and TopComponentManagerTest

  Set<TopComponent> _currentTopComponents = new HashSet<TopComponent>();

  @Before
  void setUp() throws Exception {
    _currentTopComponents.add(_childTopComponent1);
    _currentTopComponents.add(_childTopComponent2);
  }

  void testgetNeededTopComponents(){

    Deencapsulation.invoke(_topComponentManager, "getNeededTopComponents", _currentTopComponents);

    new Verifications(){{
      verify that only _childTopComponent2 is returned;
    }};

  }

}

ご覧のとおり、TopComponentManager のテスト中に、このパッケージでは不明であると判断された必要な要素を検証する必要があります。

4

4 に答える 4

2

TopComponent直接モックしてみませんか？

例：

@Mocked
TopComponent _childTopComponent1;
于 2012-12-19T07:32:15.933 に答える
0

テストクラスのみを含む新しいプロジェクトを作成することで、この問題を解決しました。このテスト クラスには、コード ベース全体に分散されたTopComponentManagerおよびすべての子への依存関係がありました。TopComponentただし、依存関係は問題ではありません。

このアプローチにより、このプロジェクト内により多くのテストを実装でき、製品コードに追加の依存関係を作成することはありません。

于 2012-12-21T04:53:18.063 に答える
0

おそらく、いくつかのコードを使用できれば、答えを出すのが簡単になるでしょう.

また、いつだけを認識しているのかをどのように呼びSuperClassManagerますManagerかSuperClass? 内の依存関係SuperClassですか？その場合SuperClassは、依存関係が間違っているため、これを から削除することを検討する必要がありますSuperClass。

ただし、マネージャーが を認識しておらずSCM、 のみを認識しているSuperClass場合は、 をモックする必要があります。SuperClassこれは、 のテストがManager他のコンポーネントのコードに依存してはならず、不要な依存関係を作成してはならないためです。

于 2012-12-18T12:04:50.207 に答える
0

それがあなたが探しているものかどうかはわかりませんが、 Mockitoは、モックのメソッドが呼び出されたときにモックを返す方法を提供します。

SCM scmMock = Mockito.mock(SCM.class, Mockito.RETURNS_MOCKS);
// scmMock.someMethod() will return a mock
于 2012-12-17T10:22:24.517 に答える