プロジェクトに単体テストを実装しようとするとき、静的メソッド、静的クラス、およびシングルトンは悪であると読んでいます。TDD パラダイムに従うとき、それらが存在したことを忘れて二度と使用しないようにする必要がありますか、それとも時々使用しても問題ないでしょうか?
4198 次
4 に答える
10
決して言わないでください。静的クラスとメソッドは、ツールボックスに配置されています。
つまり、分離してテストしようとしているクラス (テスト対象または SUT) が静的クラスまたはメソッドに依存している場合、その静的依存関係から SUT を分離するテストを作成することはできません。実行しても、静的呼び出しが使用されます。これで問題ない場合もありますが、依存関係のない SUT のロジックのみをテストする分離されたテストを作成したい場合もあります (通常は、モックまたは同様の手法を使用します)。
一般に、私は個人的に静的クラスとメソッドを比較的控えめに使用しています。
シングルトンの実装方法の性質上、単体テスト用の SUT を分離する際に同様の問題が発生します。さらに、GOF シングルトンの概念は、一定の割合のソフトウェア開発者によって悪い習慣であると考えられています。私はたまたまこの意見に同意しますが、この件に関してはほとんどコンセンサスがありません。Google で簡単に検索すると、おそらく GOF Singleton パターンの長所と短所についてかなり良いアイデアが得られるでしょう。
于 2011-03-30T13:16:12.573 に答える
3
- それらが存在したことを忘れるべきですか？いいえ。
- それらがクラスの機能に対して透過的であるような方法でコードに組み込まれていることを確認する必要がありますか？はい。
その最後の部分をさらに説明するために、コード内のシングルトンから値を取得しようとする代わりに、コンストラクター引数内の値を初期化してみてください。コンストラクターが大きくなりすぎる場合は、作成用のファクトリメソッドを作成して、シングルトンを使用せずにクラスをテストできるようにします。それが問題であることが判明した場合、またはシングルトンの状態が変更可能である場合（私はそれが怖いですが、それは私です）、シングルトンをテストにできるだけ簡単に組み込むことができるようにしてください。
4時間にわたって株価のブロックの標準偏差を計算するクラスでメソッドをテストするためだけに、構成ファイル全体を作成する必要はありません。それは大変な作業です。ただし、シングルトンがデータで埋められ、別のクラスが構成ファイルの読み取りとそのデータの入力を担当するように記述されている場合は、大きな進歩を遂げています。
静的メソッドに関しては、グローバル状態について心配する必要がないという条件に基づいて記述できる最も簡単にテストできるメソッドであると私は主張します。静的は、単純に見えるものと同等y = f(x)ですが、ローカル状態遷移が不変条件を変更できないという事実の根底にあり、特定のx場合は常に同じになりyます。
于 2011-03-30T13:08:48.257 に答える
2
あらゆるソフトウェア エンジニアリングの実践と同様に、どのような状況にも 1 つの決定的な解決策はありません。したがって、静的メソッド、静的クラス、およびシングルトンを除外しないでください。TDD の目的は、生活を楽にすることです。TDD を使用するにつれて、コードがモジュール化され、静的メソッド (... など) を使用している場合でもコードがテスト可能になることに気付くでしょう。
私が従うのが好きなルールは次のとおりです。コードが読みやすく、デザインがエレガントである限り、好きなものを使用してください。この 2 つを達成する方法はあなた次第です。それでもエレガントなコードを提供できる場合は、GOTOを使用することもできます。
于 2011-03-30T13:02:44.517 に答える
-2
単体テストを実装しようとすると、静的メソッドは悪であると読んでいます
私はそれを読んだことがありません。参照を提供していただけますか？そして、私はそれに異議を唱えます。私は常に静的メソッド (関数) を使用し、単体テストを行っていますが、問題はありません。
編集済み
Static Methods are Death to Testabilityへの参照をありがとう: その記事はガベージです。
静的メソッドの基本的な問題は、それらが手続き型のコードであることです。手続き型コードを単体テストする方法がわかりません。
これは、作成者が単体テストについてあまり知らないことを示しています。もちろん、手続き型コードを単体テストすることもできます。
インスタンス化中に、実際の依存関係を置き換えるモック/フレンドリーで依存関係を配線します。
これが重要な間違いです: 単体テストにはモック オブジェクトが必要であるという考えです。そうではありません。いずれの場合でも、モック オブジェクトを引数としてテスト中の静的メソッドに渡すことができます。依存性注入にはコンストラクターは必要ありません。詳細については、質問「静的メソッド: 時と時でない場合」の受け入れられた回答を参照してください。
静的メソッドが別の静的メソッドを呼び出す場合、呼び出されたメソッドの依存関係をオーバーライドする方法はありません。
本当ですが、無関係です。静的メソッドAが静的メソッドBを呼び出す場合、それはメソッドAの実装の詳細です。したがって、 Bへの呼び出しを傍受しようとするビジネスはありません。Aをユニットとして扱うだけです。
アプリケーションに静的メソッドしかないとします
ストローマンの議論。明らかに、現代の単体テストのコンテキストでは、いくつかの静的メソッドのみを持つ OO プログラムについて話している。
于 2011-03-30T13:13:50.393 に答える