プライベート関数は決してテストされるべきではなく、パブリックインターフェイスのみがテストされるべきだと思いました。
しかし、XDebugを使用して私の関数のカバレッジを確認すると、プライベート関数を考慮に入れると、関数のカバレッジが減少することがわかります。
あなたはそれについてどう思いますか?ありがとう。
プライベート関数は決してテストされるべきではなく、パブリックインターフェイスのみがテストされるべきだと思いました。
しかし、XDebugを使用して私の関数のカバレッジを確認すると、プライベート関数を考慮に入れると、関数のカバレッジが減少することがわかります。
あなたはそれについてどう思いますか?ありがとう。
プライベートとプロテクトを含め、すべてのメソッドをテストする必要があると思います。それらには、他のクラスへの可視性にもかかわらず、テストする必要のあるロジックが含まれています。保護されたメソッドをテストするには、多くの場合、メソッドをパブリックにするプロキシクラスを作成する必要があります。
class MyClass {
protected function protected_method() {
// do stuff
}
}
テストケースでは、別のクラスを作成し、その保護されたメソッドをパブリックにします。
class TestMyClass extends MyClass {
public function protected_method() {
return parent::protected_method();
}
}
TestMyClass::protected_method()
これで、テストケース内でテストできます。
これはそれを行う唯一の方法ではありません。PHPUnitの作成者であるSebastianBergmannは、ここにそれについてのブログ投稿を書きました:http ://sebastian-bergmann.de/archives/881-Testing-Your-Privates.html
プライベート/保護されたメソッドがテストの一部として実行されることを確認する必要がありますが、直接テストしないでください。プライベート メソッドが存在する場合は、どこかでパブリック メソッドによって呼び出される必要があります。したがって、プライベート メソッドを呼び出す方法でそのパブリック メソッドを呼び出します。
テストの優れた点の 1 つは、テストを変更することなく、コードを大幅にリファクタリングできることです。テストは、すべてが再び機能するようになったときに通知するためのアンカーとして配置されます。プライベート メソッドをテストすると、テストがコードに密接に結合されてしまい、テストとコードを同時に変更する必要があるため、そのような大きなリファクタリングが面倒になります。