0

したがって、単体テストを実行したい以下のメソッドがあります。

public List<Project> getProjects(Task task) {

    Criteria<Project> criteria = this.myRepository.getCriteria(Project.class);
    criteria.add(Comparison.eq("order", task.getOrder()));
    criteria.addOrder(Order.asc("projectNumber"));
    return this.myRepository.findList(Project.class, criteria);
}

したがって、実際にはタスクオブジェクト（JPAモデルオブジェクトです）を取得し、プロジェクトテーブルをスローして、このプロジェクトの注文を持つすべてのプロジェクトを見つけます。順序は両方の表で共通です。

とにかく、クエリ自体はそれほどインプではありません。db にクエリを実行し、いくつかのデータを返します。さて、私の問題は、easymock を使用してこれに対して単体テストを実行するにはどうすればよいですか?

@Test
public void testGetProjects() throws Exception {
    myRepository = new CreateMyRepositoryWrapper(); --> This is a class which just returns the entityManger. but here we can consider this as a pojo.

    Task task = EasyMock.createNiceMock(Task.class);
    Order bom = EasyMock.createNiceMock(Order.class);        
    Project project= EasyMock.createNiceMock(Project.class);

    project.setProjectName("project"); ------> Can I call a seeter on a mocked object?

    project.setProjectNumber("1");

    EasyMock.replay(project);

    List projects= new ArrayList(Arrays.asList(project));
    bom.setProjects(projects);  ------------> Does it make sense to do this?

    EasyMock.expect(task.getOrders()).andReturn(bom);
    TestClass instance = new TestClass();
    instance.setMyRepository(myRepository);

    EasyMock.replay(task,bom);
   instance.getProjects(task);

}

したがって、これはテストケースに合格します。しかし、私が実際にテストしていることを嘲笑しているすべての人に確信が持てません..それらのメソッドが呼び出されていることを示しているだけだからです。しかし、それらは嘲笑されているため、 assertEquals を使用できるかどうかはわかりません。使用できる場合でも、上記のコードにさらに追加する必要があるため、例外が発生しています。

だから私の質問：言及された方法について、適切な単体テストケースは何ですか？

ありがとう。

4

1 に答える 1

1

私はあなたがこれを後ろ向きに嘲笑していると思います。myRepostoryをモックし、myRepositoryモックを設定して、Criteriaオブジェクトを返し、そのCriteriaオブジェクトがfindListに渡されたときにプロジェクトリストを返します。

タスク、注文、プロジェクトはおそらくインスタンス化することができます。

これで、instance.getProjects（task）は何かを返します。返されたものが、findListから返される必要があると言ったものと同じであることを確認できます。これで、特に興味深いものはありませんが、実際に何かをテストしました。

findListに渡される前に、criteriaオブジェクトが正しく設定されていることを検証する必要があります。そのためには、基準をモックにする必要があります。次に、どのメソッドが呼び出されるかについての期待を設定できます。ここで注意が必要なのは、Hibernateの制限クラスにはデフォルト以外のequals実装がないため、基準に渡される制限が期待する制限と（機能的に）同じであることを確認するために独自のマッチャーを作成する必要があることです。

もう1つの可能性は、実際のCriteriaオブジェクトとして基準を設定することです。（myRepositoryモックを設定して返します。）次に、関数が呼び出された後、toString（）メソッドまたはCriteriaオブジェクトを検査するために知っている他の方法で、部分文字列が一致する内容を確認できます。

最後の（単体テスト）可能性は、Criteriaオブジェクトにモックフレームワークを使用しないことですが、それに追加されたすべての制限を検査できるように、手書きで作成したフレームワークを使用します。

これらすべてが、代わりに統合テストで実際にテストされているこのメソッドの良い例になります。あまり面白くないことを検証するために多くの作業を行うことになり、コードをリファクタリングしようとすると、テストが非常に脆弱になる可能性があります。（私は自分でやったので、経験から話します。）

于 2012-07-19T06:25:42.670 に答える