ユニットテストについて、文句を言いたいです.

現在、プロジェクトにはユニットテストがないので、皆さんはずっとスローガンを呼んでいます.ユニットテストを使うには、テストが開発を駆動できるかどうかは言いにくいですが(これは難しいと思います)、少なくともテストはいくつかの問題の発生を減らすのに役立つでしょう.ユニットテストを始めたばかりの頃は、テストがコードの前に書くか、後で書くかを気にする必要はありません.「テストは開発の負担ではなく開発を助けるツール」の状態に達することが現段階のタスクです.
次に、ユニットテストjunitと私のわずかな理解について、私の愚痴の所在を述べましょう.
まず、従来のプロセスのユニットテストは典型的なホワイトボックステストであり、コードの発生はどこでもエラーが発生する可能性があると思います.このエラーは異常な中断、エラーの戻り値、データベースを格納する際に記録が少なく、遠隔クライアントに送信される情報が不完全であるなど様々ですが、junitはブラックボックス方式、すなわち戻り値で発生する可能性のあるエラーをキャプチャするしかありません.ユニットテストエラーの多様性のため,すべてのタイプのエラーをキャプチャするための統一的な方法を抽象化することはほとんど不可能である.junitだけならできることは少ないですが、JMOCK、ORMUSIT、DBUNIT、XMLUNITがあるので...などのツールはテストを助けて、経典の開発環境の下で(フォーラムの中で多くの人が置かれている環境のように)、junitはそれらのツールと協力してプログラムを助けることができて多くの問題を萌芽の中で発見します.
POJO IN ACTIONのユニットテスト使用例をよく見ました
ビジネスクラスのテストはこの形式です.

Class Book{   
    BookDao dao ;   
    public Book(BookDao dao){   
       this.dao = dao;   
    }   
  
    public doSomething(){   
       ......   
    }   
}   
// book doSomething()    
Class usertest extends  MockObjectTestCase{   
   private Mock daoMock;   
   private Book;   
   public viod setUp(){   
       daoMock = new Mock(BookDao.class);   
       BookDao = (BookDao)daoMock.proxy();   
       Book = new Book(BookDao);   
   }   
   public void testDoSomething(){   
       daoMock.expects(once())   
              .method("add")   
              .with(eq(1))   
              .will(returnValue(true));   
       Book.doSomething();   
   }   

    Class Book{
        BookDao dao ;
        public Book(BookDao dao){
           this.dao = dao;
        }

        public doSomething(){
           ......
        }
    }
// book doSomething() 
    Class usertest extends  MockObjectTestCase{
       private Mock daoMock;
       private Book;
       public viod setUp(){
           daoMock = new Mock(BookDao.class);
           BookDao = (BookDao)daoMock.proxy();
           Book = new Book(BookDao);
       }
       public void testDoSomething(){
           daoMock.expects(once())
                  .method("add")
                  .with(eq(1))
                  .will(returnValue(true));
           Book.doSomething();
       }
   }

問題は、プロジェクトの誰もがこのようにbookを書いているのではなく、そう書いている人がいるかもしれないということです.

Class Book{   
    public doSomething(){   
       BookDao dao = new BookDao();   
    }   
}  

    Class Book{
        public doSomething(){
           BookDao dao = new BookDao();
        }
    }

このようにBookDaoは構造子注入ではなくエージェントオブジェクトで置き換えることはできませんが,このように書かれたビジネスクラスはテストできないかもしれません.の
私はここでこのようなコードを書く開発者の素質が高いかどうかについて議論したくありません.私が愚痴をこぼしたいのは、テスト自体と開発は2つの異なる考え方ですが、ユニットテストは簡単にはできません.彼はビジネスを開発する人が気を配る必要があります.冗長で複雑なビジネスに陥っている以外に、コードをどのように書くかを考えてコードをテストすることができます.これは少し本末転倒しているようだ.ユニットテストを実現するには、まずテスト可能なビジネスコードを書く方法を知ってから、テストクラスがどのように書くかを考えなければならないようです.
これらは何も感じていないように見えますが、従来のSSH慣用方法のビジネスクラスに従ってioc工場を通じてコンポーネントをフレームワークの制限から離れて「ローカライズ可能」なpojoクラスにすると、天然地もテスト可能クラスになります.
しかし、オープンソースフレームワークではなく、「顧客に売り込むための」社内フレームワークだけで開発することができ、フレームワークの制限はクラスを書くことしかできないことが多い.

   public doSomething(){
     BookDao dao = new BookDao();
   }

形式の場合、ユニットテストはそんなに簡単ではありません.