☰

ユニットテストのアクセサ（ゲッターとセッター） 質問する

tag-icon • tag-icon php unit-testing phpunit accessor getter-setter
ユニットテストのアクセサ（ゲッターとセッター） 質問する

以下の方法があるとします。

public function setFoo($foo) {
    $this->_foo = $foo;
    return $this;
}

public function getFoo() {
    return $this->_foo;
}

将来的にはより複雑なものに変更される可能性があります。

  • これらのメソッドの単体テストはどのように記述しますか?
  • テスト方法は1つだけですか?
  • それらのテストをスキップしたほうがよいでしょうか?
  • コードカバレッジはどうですか?
  • 注釈はどうですか@covers?
  • 抽象テストケースに実装する汎用的なテストメソッドがあるでしょうか?

(私はNetbeans 7を使用しています)

これは時間の無駄のように思えますが、IDE がそれらのテスト メソッドを自動的に生成してもかまいません。

にセバスチャン・バーグマンのブログのコメントからの引用:

(ゲッターとセッターをテストするのと同じです -- 失敗します!) いずれにせよ、これらが失敗した場合、それらに依存するメソッドは失敗するのではないでしょうか?

では、コードカバレッジはどうでしょうか?

ベストアンサー1

TDD を実行する場合は、ゲッターとセッターのテストも記述する必要があります。コードが非常に単純な場合でも、テストなしで 1 行もコードを記述しないでください。

テストにゲッターとセッターを併用したり、ユニット テスト フレームワークの機能を使用して保護されたクラス メンバーにアクセスしてそれぞれを分離したりするのは、一種の宗教戦争です。ブラック ボックス テスターとして、私はユニット テスト コードを具体的な実装の詳細に結び付けるのではなく、パブリック API に結び付けることを好みます。私は変化を期待しています。開発者に既存のコードをリファクタリングするよう促したいのです。また、クラスの内部は「外部コード」(この場合はユニット テスト) に影響を与えてはなりません。内部が変更されたときにユニット テストが中断されるのではなく、パブリック API が変更されたとき、または動作が変更されたときにユニット テストが中断されるようにしたいのです。ユニット テストが失敗する場合は、問題の唯一の原因を特定しないでください。問題の原因を突き止めるには、ゲッターとセッターの両方を調べる必要があります。ほとんどの場合、ゲッターは非常に単純です (5 行未満のコード: たとえば、戻り値と例外を伴うオプションの null チェック)。したがって、最初にこれをチェックすることは大したことではなく、時間がかかりません。また、セッターのハッピー パスのチェックは、ほとんどの場合、少しだけ複雑になります (検証チェックがいくつかある場合でも)。

テスト ケースを分離するようにしてください。他の方法 (上記の例を除く) に頼らずに、その正確性を検証する SUT (テスト対象) のテストを作成します。テストを分離すればするほど、テストで問題が見つかる可能性が高くなります。

テスト戦略によっては、ハッピー パスのみをカバーしたい場合があります (実用的なプログラマー)。または、サッド パスもカバーしたい場合があります。私は、すべての実行パスをカバーすることを好みます。すべての実行パスを発見したと思ったら、コード カバレッジをチェックしてデッド コードを特定します (発見されていない実行パスがあるかどうかを特定するためではありません。100% のコード カバレッジは誤解を招く指標です)。

ブラック ボックス テスターに​​とってベスト プラクティスは、phpunit を厳密モードで使用し、@covers を使用して付随的なカバレッジを非表示にすることです。

ユニット テストを記述する場合、クラス A のテストはクラス B とは独立して実行する必要があります。したがって、クラス A のユニット テストでは、クラス B のメソッドを呼び出さないようにしたり、カバーしたりしないでください。

廃止された getter/setter やその他の「デッド」メソッド (製品コードでは使用されていない) を識別する場合は、静的コード分析を使用します。関心のあるメトリックは、「メソッド レベルでの求心性結合 (MethodCa)」と呼ばれます。残念ながら、このメトリック (ca) は PHP Depend のメソッド レベルでは使用できません (参照:http://pdepend.org/documentation/software-metrics/index.htmlそしてhttp://pdepend.org/documentation/software-metrics/afferent-coupling.html)。本当に必要な場合は、PHP Depend にお気軽に投稿してください。同じクラスからの呼び出しを除外するオプションは、「付随的な」呼び出しなしで結果を取得するのに役立ちます。「デッド メソッド」を特定した場合は、それが近い将来に使用されることを意図しているかどうか (@depricated アノテーションを持つ他のメソッドの対応物) を判断し、そうでない場合は削除します。同じクラスでのみ使用される場合は、privat / protected にします。このルールをライブラリ コードに適用しないでください。

プラン B: 受け入れテスト (統合テスト、回帰テストなど) がある場合は、ユニット テストを同時に実行せずに、また phpunits の厳密モードを使用せずに、そのテストを実行できます。これにより、実稼働コードを分析した場合と非常によく似たコード カバレッジ結果が得られます。ただし、ほとんどの場合、非ユニット テストは実稼働コードほど強力ではありません。このプラン B が実稼働コードと「十分に同等」で意味のある結果を得るかどうかは、分野によって異なります。

さらに読む: - 書籍: Pragmatic Programmer - 書籍: Clean Code

おすすめ記事