コンストラクターを単体テストする必要がありますか? 次のようなコンストラクタがあるとします。
IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
this.wrapper = mapinfoWrapper;
}
このコンストラクターの単体テストを作成する必要がありますか? ラッパー変数のゲッターがないため、テストする必要はありません。
コンストラクターを単体テストする必要がありますか? 次のようなコンストラクタがあるとします。
IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
this.wrapper = mapinfoWrapper;
}
このコンストラクターの単体テストを作成する必要がありますか? ラッパー変数のゲッターがないため、テストする必要はありません。
単体テストとは、オブジェクトの公開状態、動作、および相互作用をテストすることです。
コンストラクターにプライベート フィールドを設定するだけで、何をテストする必要があるでしょうか。
単純なアクセサーとミューテーターの単体テストを気にしないでください。それはばかげているだけで、誰の助けにもなりません。
はい。コンストラクターにロジックがある場合は、それをテストする必要があります。単純にプロパティを設定することは、論理的な IMO ではありません。条件、制御フローなどはロジックです。
編集: その依存関係が必要な場合は、おそらく IMapinfoWrapper が null であることをテストする必要があります。もしそうなら、それはロジックであり、ArgumentNullException などをキャッチするテストが必要です... テストは、コードの動作を定義する仕様です。ArgumentNullException をスローする場合は、テストで指定する必要があります。
Q: コンストラクターでメンバー変数を設定している場合、なぜ設定するのですか?
A: コンストラクターで設定することによってのみ成功させることができる失敗した単体テストがあるためです。
単体テストに合格するためのコードのみを記述するこのロジック (テスト駆動開発) を使用すると、質問に対する答えが既に得られます。
いいえ。その機能は、クラスの他のすべての単体テストによってテストされます。
コンストラクターは絶対にテストする必要があります。デフォルトのコンストラクターがある場合は、それを呼び出すことができることをテストする必要があります。後でクラスが変更された場合、おそらくシングルトンになるか、パラメーターを必要とするコンストラクターが優先されてデフォルトのコンストラクターが削除された場合はどうなるでしょうか? その場合、テストは失敗してその変更を警告する必要があります (新しい要件を満たすようにクラスまたはテストを修正できるようにするため)。
デフォルトのコンストラクターの存在は、テストが必要な要件です。コンストラクターが行うのは、他の場所でテストされるプライベート メンバーの設定だけであっても、パラメーターのないコンストラクターがあるという事実をテストする必要があります。
場合によります。
あなたが与えた例のように単純なもののために専用のコンストラクターテストをわざわざ書くつもりはありません。
ただし、コンストラクターにパラメーターの検証などの論理テストがある場合は、絶対にそうです。元の投稿者のように、可能な限りコンストラクターで作業を行いませんが、パラメーターの検証を行う必要があるのは一般的です。この場合、コンストラクターが何らかの作業を行わないようにすることは避けられません。コンストラクターにロジックがある場合、それが間違っている可能性が常にあるため、他のメソッド呼び出しと同じように扱い、適切にテストします。
多くの FDA 規制環境では、クラスの構築を含め、より重要なコードを 100% テストする必要があります。したがって、コンストラクターをテストするかどうかに関係なく、コンストラクターのテストが必要になる場合があります。また、静的分析ツールを使用する企業は、コードがスムーズに実行され、エラーがなくても、エラーが発生しないようにするために、クラスのすべてのデータ メンバーが適切に初期化されていることを確認する必要があります。通常、データ メンバーの初期化はコンストラクターで行われます。
私は100%のカバレッジを信じています。また、物事をモックしたり、設定して取得したりするだけで単純な相互作用をテストするだけでなく、機能をチェックする統合/受け入れテストをさらに100%カバーします。したがって、本当に優れた統合/受け入れテストを作成することになった場合は、すべてのコンストラクター(およびセッターやゲッターなどの単純なメソッド)を呼び出す必要があります。
開発者が状態ロジックを変更できないことを確認していない限り、アクセサーとミューテーターのテストも必要です。たとえば、Singleton のデザイン パターンを使用する場合、多くの場合、アクセサーまたはプロパティが使用されます。クラスが初期化されていない場合は、コンストラクターがプライベートであるため、アクセサーから実行されます。C++ では、クラスのデータ メンバーを変更できない関数を const または static にすることができます。(注: これらの変数はグローバルであることが多いため、static を使用することも少し危険です。) しかし、テストなしで、誰かが予防手段を使用できなかった場合、書き込まれたものが失敗にならないことを 100% の精度でどのように保証できますか?時間?メンテナンスは簡単ではありません。
のインスタンスのどのような動作は、SystemInfo
の値に依存しますwrapper
か?
何かがうまくいかない場合(たとえば、null値が破損を引き起こす場合)、そのような状況をそれぞれ説明するシナリオを作成し、それらを使用して適切な単体テストの定義を推進することをお勧めします。
すべてのシナリオがのプライベートインスタンスの状態または動作に依存することになった場合はIMapinfoWrapper
、代わりにそのクラスで単体テストを作成することをお勧めします。
コンパイラーを作成している場合を除き、コンパイラーが割り当てを行うコードを生成できることをテストするだけなので、通常は無意味です。
さて、より一般的な状況では、ラッパーで何か他のことをしたい場合は、おそらくポイントがあります. たとえば、null を渡そうとした場合、ArgumentNullException をスローすることができます。理論的には、単体テストを行うことができます。それでも、テストの価値はごくわずかです。
個人的には、コンストラクターを明示的にテストすることはほとんどありません。テストが必要なほど複雑な場合、コードが少し臭いと感じる傾向があります。
コンストラクターにクラスの初期化などのロジックが含まれている場合は、コンストラクター自体をテストする必要があると思います。または、コンストラクターに初期化を入れるとテスト対象のコードのテスト容易性が低下することを開発者に相談することもできます。
ユニットテストは、実行パスをチェックすることです。これは、循環的複雑度と呼ばれることがよくあります。
選択するパスがない場合、if、ループ、GOTO(= P)がない場合はあまり役に立ちません