しけんせっちゃくど

最近、オペレータが処理するユニットテストを書いています.liangfeiが言ったように、式をよりよく最適化するには、まずオペレータの機能を十分に理解しなければなりません.書き込みユニットテストは非常に良い方法です.この観点に非常に賛成しているので、私は最近ずっとテストを書いていて、オペレータの機能も確かに理解しています.
 
テストクラスでオペレータオブジェクトをどのように取得しますか?書き終わったテストクラスを参考にしてみると、newが出てきたことに気づきました.しかし、プログラムでは、オペレータはnewではなく、IOCコンテナを通じて取得され、あるオペレータであるhandlerを取得します.例えば、次のようにします.
 

Configuration config = PropertiesConfigurationLoader.loadStandardConfiguration();
//   StandardOperatorHandlerProvider
operatorHandlerProvider = config.getOperatorHandlerProvider();
handler = operatorHandlerProvider.getUnaryOperatorHandler(".");

 
このhandlerは処理です.記号の、このhandlerを通じて、更に“.”を呼び出します番号オペレータ.オペレータのリロードを実現するためだと思います.
 
したがって,CommonTemplateではオペレータオブジェクトを直接得ることは不可能である.したがって、テストクラスでは、オペレータを取得してテストする方法も使用しています.
 
しかしliangfeiはこの方法に同意していない.彼はオペレータをテストするときは、テストクラスでnewでオペレータを出して、オペレータをテストすべきだと考えています.理由は、テストするターゲット機能を区切ることができるからです.私の理解はテストの接着度を下げることです.しかし、OperatorHandlerの正確性をどのように保証するかという別の問題が発生します.
 
OperatorHandlerから各オペレータにテストするテストクラスを再作成する必要があるかもしれません.これは確かに面倒だ.しかし、このようなテストをしなければ、OperatorHandlerの正確性は保証されません.
 
では、テストの接着度はどのようにコントロールすればいいのでしょうか.たとえば、ビジネス・レイヤと永続レイヤがあるプロジェクトです.では、この2つのレイヤにテストを書くときは、どうすればいいですか?
 
理解したTDDのように,永続層を実現する際には,必然的に永続層のテストが書かれる.ビジネス層を書くときに、ビジネス層のテストを書くと、ビジネス層のテストにも間接的に永続層の内容が含まれます.永続層のテストをスキップできますか?もちろんだめです.
 
だから問題はまた戻ってきました.CommonTemplateにとって、オペレータのテストをスキップすることができますか?もちろんできません.実際にはスキップしていません.今書いているのはオペレータのテストです.では、OperatorHandlerのテストをスキップしてもいいですか?だめです.しかし,OperatorHandlerでは論理が少なく,責任チェーンのパターンに従って変数を正しいオペレータに割り当てるだけである.
 
そこで、OperatorHandlerのテストとオペレータのテストを一緒にすることができますか?このようにして試験粘着度は比較的大きいが,OperatorHandlerの論理はほとんどなく,これを単独で試験すれば試験オペレータと完全に重複する.
 
したがって、2つのクラスは、関連しているが、そのうちの1つのクラスには論理がないか、論理が非常に少ないかを考えることができるのではないでしょうか.接着度を考慮せずに、この2つのクラスを直接テストすることができますか.
 
この問題は答えが分からない.しかし、liangfeiの意見に従い、接着度を下げるようにテストクラスを修正しました.今後の積み重ねの中で、満足のいく答えが得られることを望んでいます.