facadeのテストについて

とても浅い考え、大牛が多く指導することを望みます
元のfaC adeコード

public class XxFacadeImpl implements XxFacade {
    public List doSomeThing(String param1) {
        //1 
        XXVO xxVO=new XXVO();
        xxVO.setParam(param);
        //2. 
        List xxList = xxDao.getXXList(xxVO);        //Dao 1
        //3. xxList 
		XXVO xxVO1 = new XXVO();              // 1
        For(int i=0;i<xxList.size();i++){
			xxVO1 = (XXVO) xxList.get(i);
			xxVO1.setName(String.valueOf(i));
}                          
        //4. 
        xxDao.updateXXList(xxList);                 //Dao 
        //5.                                //  2     
        return xxList;
    }
}

このようなコードはよくありますが、ビジネスコードと永続層メソッド呼び出しを一緒に書く方法はテストされにくいです.このようなメソッドをテストするには、次のような流れがあります.
1.データベースに条件を満たすデータ(insert)がparam 1のクエリー条件を満たすように準備する
2.XxFacadeImplを呼び出すdoSomeThing(1)メソッド
3.戻されたListは、ビジネスロジック1が正しいかどうかを検証する
このようなコードは無理にテストできますが、面倒なので、まずテストデータを作成し、自分がクエリーしたテーブルに関連があるかどうかを考え、テストデータを一緒に挿入しなければなりません.そうしないと、Daoロジック1はデータを得ることができず、テストに失敗します.テスト後、データをロールバックする必要があります.そうしないと、データベースにゴミデータが残ります.
明らかに我々のfaC adeはDaoの実装やテーブル内のデータに関心を持っていないが,この方法をテストするためにこのような環境をシミュレートしなければならない.しかし、ビジネスロジック2のコードについてどのようにテストしますか?彼が操作したデータはちょうどこの方法の戻り値なので、このコードを簡単に修正します.

public class XxFacadeImpl implements XxFacade {
    public boolean doSomeThing(String param1) {
        //1 
        XXVO xxVO=new XXVO();
        xxVO.setParam(param);
        //2. 
        List xxList = xxDao.getXXList(xxVO);        //Dao 1
        //3. xxList 
		XXVO xxVO1 = new XXVO();              // 1
        For(int i=0;i<xxList.size();i++){
			xxVO1 = (XXVO) xxList.get(i);
			xxVO1.setName(String.valueOf(i));
}                          
        //4. 
		//upadateXXList(xxList) 
        return xxDao.updateXXList(xxList);            
    }
}

メソッドの戻り値を簡単に修正しただけで、私たちは今このupdateメソッドが成功したかどうかだけに関心を持っています.
ビジネスロジック1をテストするにはどうすればいいですか?
まとめてみると、
テスト不可能な方法:このようなFaC adeはテストされにくく、テストできない部分や方法の論理がまったくテストされない部分もあります.
スパムデータ:データベースに大きなスパムデータが残ります.TestDaoConstantを継承することで自動的にロールバックできますが、FaC adeビジネス自体はトランザクションを必要としません.mockを導入して孤立テストを行うと、Mockがもたらす複雑さも導入されます.
コード多重化:このようなコードは通常多重化されにくい.
テストオーバーライド:方法にテストできない部分があるため、テストのオーバーライドを保証できません.
改良されたFaC adeコードは以下の通りです.

public class XxFacadeImpl implements XxFacade {
    public boolean doSomeThing(String param1) {
        //1 
        XXVO xxVO=new XXVO();
        xxVO.setParam(param);
        //2. 
        List xxList = xxDao.getXXList(xxVO);        //Dao 1
        //3. xxList 
editUserName(xxList);		                // 1
        //4. 
        xxDao.updateXXList(xxList);                 //Dao 
        //5.                                //  2  
		someBusiness2(xx);
        return true;
}
public List editUserName(List xxList){
		XXVO xxVO1 = new XXVO();              // 1
        for(int i=0;i<xxList.size();i++){
			xxVO1 = (XXVO) xxList.get(i);
			xxVO1.setName(String.valueOf(i));
}  
return xxList;
}

public List someBusiness2(xxx){
	...
	…
	…
	…
return result;
}
}

このようなコードXxFacadeのdoSomeThingメソッドはビジネスロジックの具体的な実装に関心を持っていないが、このロジックの実装プロセスだけで、彼はいくつかの純粋なビジネスメソッドを呼び出すだけで、これらの純粋なビジネスメソッドはDaoデータに依存する必要はありません.私たちは勝手にリストを組み立ててテストすることができます.私たちはデータベースを必要としません.トランザクションも抜け出して、テストする必要がありますのはこれらのきれいな純粋なビジネスメソッドだけで、彼らは簡単なパラメータに依存しています.このビジネス操作後のデータを返します.XxFacadeのdoSomeThingメソッドについては、彼をテストする必要もありません.彼が呼び出したメソッドはすべてテストされた信頼できる方法です.
簡単な変更が私たちに何をもたらしたか見てみましょう.
1.方法をテストできるようにし、テストカバー度を高める
2.トランザクションから離れ、データベースでテストできるようにする
3.有効な分割方法、各方法の業務はすべてとても簡単で、1画面の足はすでに詰めました
4.すべての純粋な業務方法が一つのことしかできないことを保証します.
5.方法が多重化される機会を高める
メソッドdoSomethingで呼び出されたすべてが信頼できるメソッドであるため,コードの品質とカバー度を直接向上させ,再構築の勇気を高めた.
最後に、有効なテストプログラムを多く提出して、私たちのコードの品質を高めて、退勤前にテストを走り回って有名なgreen barを見て家に帰って落ち着いて寝ることを望んでいます.