PHPSpec テストからカバレッジ レポートを生成する方法を知っている人はいますか?
xdebugについて考えましたが、私が知る限り、ジェンキンのレポートを生成できません。
PHPSpec テストからカバレッジ レポートを生成する方法を知っている人はいますか?
xdebugについて考えましたが、私が知る限り、ジェンキンのレポートを生成できません。
現状 (1.4.0) では、コード カバレッジはまだサポートされていません。これについてのご意見をお待ちしております。以下は、コードカバレッジに関する私の意見です。
PHPSpec は BDD フレームワークです。BDD を行っている場合は、クラスを作成する前に、クラスの動作を記述します。そのようにした場合、クラスの関連する動作はすべて「テスト」で適切にカバーされます。
コード カバレッジ ツールとメトリクスは、レガシー コード (仕様/テストなしで記述したコード) に役立ちます。そのようなツールを使用して、TDD を継続し、リグレッションから保護されるという利点を得ることができるポイントに到達することを試みることができます。
一般に、このアプローチは、最初に動作を説明する (TDD) ほど効果的ではありません。1 つのメソッドで、複数の必要な動作に対応できるほど単純な場合があります。TDD を行っているときは、その過程でリファクタリングを続け、不要なコードを削除していることをご存知でしょう。10 個の仕様 (テスト) が同じコード行をヒットすることになり、すべてが異なる必要な動作を記述し、すべてコードを理解するのに役立ちます。
「テスト」という言葉の問題点の 1 つは、TDD が検証に関するものだと人々に思わせることです。そうではありません。コミュニケーションについてです。StoryBDD は利害関係者間のコミュニケーションであり、SpecBDD はクラス間のコミュニケーションです。シンプルで生き生きとした、十分なドキュメント。
コードをテストしたことを保証するために行われるコード カバレッジは誤りであり、せいぜい貧弱な指標です。残念ながら、人々はテスト構造がテスト動作よりも重要であると考えています。BDD が誕生した理由は、焦点を正しい軌道に戻すためです。コードのこの部分がテストされていることを確認することは、コードのその部分が複数のことを実行できるため、偽物です。また、アクセサー、修飾子、コンストラクターなどをテストすることになります。
しかし、私はこれについてコミュニティに耳を傾けます。コード カバレッジがどこで役立つかがわかります。さらに、Sebastian Bergmann が PHPUnit からうまくモジュール化したので、PHPSpec で再利用できました。最初にスペックを書いた方がいいと思います。関連する動作の 100% のコード カバレッジを無料で取得できます。私の見解では、それが最も重要なことです。
コードカバレッジジェネレーターは、テストされていないコードを特定できるため、BDDスタイルのテストを受けているレガシーシステムに役立つと思います。私は、PHPSpecのそのような機能に感謝します。