アクセサのユニットテストは必須ですか？

Question

他のメソッドのほかにいくつかのセッターとゲッターを持つクラスの場合、アクセサのユニットテストを書いて、残りのインターフェースをテストしながら呼び出されることを考慮して、時間を節約するのは妥当ですか？

Answer 1

絶対に。単体テストのアイデアは、変更が未知の方法で動作に影響を与えないことを保証することです。 getFoo()のテストを書かないことで時間を節約できます。 Fooのタイプを少し複雑に変更すると、アクセサーをテストすることを簡単に忘れることができます。あなたがテストを書くべきかどうかを質問しているなら、あなたはそれを書いた方が良いです。

IMHOでは、メソッドのテストを追加することをスキップすることを考えている場合は、メソッドが必要かどうかを自問したいと思うかもしれません。完全な開示のために、私はのうちの一つであり、必要があると証明された場合にのみセッターまたはゲッターを追加する人々です。あなたは実際に建設後に特定のメンバーにアクセスする必要がないか、メンバーに本当に依存している計算結果にアクセスしたいだけなのか、何度頻繁に驚くでしょう。しかし、私は逃げる。

良いマントラは、常にテストを追加することです。方法が些細なので、必要と思わない場合は、代わりにメソッドを削除することを検討してください。一般的なアドバイスは、"簡潔な"メソッドのテストをスキップしても問題ありませんが、メソッドが必要なのかどうかを自分で確認する必要があるということです。テストをスキップすると、その方法は常にとなります。ユニットテストはインテントとコントラクトのドキュメントとしても機能することに注意してください。したがって、簡単な方法のテストでは、この方法は実際には些細なものであることが示されています。

Answer 2

変数を設定したり返す以上のことをしたら、私はそれらを単体テストします。ある時点で、コンパイラが適切なプログラムを生成することを信頼する必要があります。

Answer 3

私は単体テストが好きです。アクセサーが単にフィールドを返す以外に何らかの作業を行う場合、そのコードは適切にテストされます。

フィールドを返す以外に何もしない場合でも、余分な処理を行うために後で変更される可能性があります。

また、実行されているテストの数を簡単に増やすことができます。これは、多くの管理者が好むものです。

Answer 4

IDEがメンバーアクセサの変更を生成して管理している場合は、特別な処理を行う必要はありません。次に、それらを実際にテストすることは重要ではありません。タイプは一致し、テンプレートなどの名前が付けられます。

Answer 5

私のテスト基準は、条件付きロジック（while、if、forなど）を含むすべてのコードがテストされることです。アクセサーが単純なgetter/setterの場合、それらをテストすることは時間を無駄にしていると思います。

Answer 6

私は、時間を節約し、特に役に立つとは思わない単体テストを書くのは妥当だと思います。

100％テストカバレッジは優れた理想的なものですが、テストを書いていた時間があなたがそれを得ることから得られる利益に値するものではない場合、リターンが小さくなることもあります。

単体テストが役に立つと判断した場合は、いつでも後でユニットテストを追加して追加することができます。

Answer 7

私はほとんどの人がそれらをテストすると言うと時間が無駄だと思います。本当の99％の場合。アクセサーにバグがあり、ユニットテストの残りの部分が間接的にそれをキャッチしていない場合、なぜそのプロパティが存在するのか疑問に思うでしょう。

一方、アクセサをテストすることは、この質問をして:)

は個人的に私はそれらをテストすることが少ないタイピングをとります。しかし、これは私のための灰色の領域であり、クラスの機能性を十分にカバーしている限り、グループ内の他の人にテストしてもらうことはありません。

通常

Answer 8

私は自分自身に次のことを尋ねるユニットテスト書き込みを考慮してください。

1. は、DALの上に何かをアクセスするゲッター/セッター（データアクセス層）ですが？

もしそうなら、私は単体テストを含むでしょう。その場合、将来のある時点で、遅延ロードを実装するか、単純なget/setより高度なものを実装することにした場合、これが適切に動作することを確認する必要があるためです。

2. getter/setterが例外をスローすることはできますか？

ゲッターのベストプラクティスは、例外をスローすることを許可しないことです。セッターは別の問題です。しかし、どちらの方法でも、プロパティが例外をスローする可能性があると判断した場合は、そのプロパティの単体テストを作成して、成功したアクセスと意図的に例外を生成することができます。

ダンは次のように指摘しています。「ある時点で、コンパイラが適切なプログラムを生成すると確信する必要があります。

Answer 9

当社には、人々と意見の両方があります。彼らは通常、自動的に

が（別のテストのコンテキストでテスト生成

• あるとして、私は、それらを特異的にテストしていないする傾向だ例えば
• 任意のコードを含まないこれらのアクセサのいくつかの他のコード活かしあります
  • 彼らは単にグラムでないとき：それは例外ががあります

  を壊すかもしれませんenerated「ゲッター」と「セッター」

• 彼らはただ、他のユーザーのために提供し、本当にあなたが

両方で現在、これらの例かもしれない原因だコンテキストでテストされていない重要なAPIの一部であります私はそれらをテストする。最初のものは2番目のものより多い。

Answer 10

いいえ。 時間の無駄です！

でもボブ・マーティンSee SO podcast 41でも、アジャイルの祖父は言いません。

Answer 11

論理を含まないプロパティに対してテストを書く必要はありません。

単純なプロパティをテストする唯一の説明はテストカバレッジを高めることですが、それはちょっとばかりです。