10
コードカバレッジ品質の議論に反論する方法に関するツール/提案
今、私は人々がこの質問を複製したり何度も質問したりすることを考えることができることを知っています。その場合、関連する質問へのリンクと私の質問への回答に感謝します。 私は最近、コードカバレッジについて何人かの人々と意見が分かれています。私は、100％のカバレッジは高品質のテスト、したがって高品質のコードを意味しないという議論に基づいて、チームにコードカバレッジを完全に削除することを希望する人々のグループがいます。 私は、コードカバレッジがテストされていないことを確かに伝えており、それらの領域に集中するのに役立つという議論を売り払うことによって押し戻すことができました。 （上記は、このような他のSO質問で同様の方法で議論されています-/programming/695811/pitfalls-of-code-coverage） これらの人々からの議論は次のとおりです。そして、チームは低品質のテストをすばやく作成することで反応し、重要な品質を追加することなく時間を無駄にします。 私は彼らの視点を理解していますが、より多くのカバレッジ基準を処理するより堅牢なツール/フレームワークを 導入することにより、コードカバレッジのより堅牢なケースを作成する方法を探しています(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)。 私が探しているのは、このようなコードカバレッジツールとプラクティス/プロセスの組み合わせを提案して、それらに合うようにすることです。 主観的ではあるが、コードカバレッジによりコードの品質とテストの価値をより意識できるようになったため、このような議論に対抗する方法に関するあなたの経験/知識に基づいた付随するコメント/提案も歓迎します。 編集：典型的なコードカバレッジの弱さに対する私の理解に関する混乱を減らすために、ツール（または実行されたコードの行）を参照しているわけではない ことを指摘したいと思いStatement Coverageます（たくさんあります）。実際には、ここでそれが間違っているすべてに関する良い記事があります：http : //www.bullseye.com/statementCoverage.html 複数のカバレッジの基準とレベルにさらに踏み込んで、ステートメントまたはラインカバレッジ以上のものを探していました。 参照：http : //en.wikipedia.org/wiki/Code_coverage#Coverage_criteria アイデアは、ツールが複数の基準に基づいてカバレッジを教えてくれれば、それがテスト品質の合理的な自動評価になるということです。私は決して回線カバレッジが良い評価だと言っているわけではありません。実際、それが私の質問の前提です。 編集： わかりました、多分私はそれを少し劇的に投影しすぎたかもしれませんが、あなたはポイントを得ます。問題は、すべてのチームに共通のプロセス/ポリシーを同種/一貫した方法で設定することです。また、テストの品質をどのように保証するのか、何の対策も講じずに保証時間をどのように割り当てるのかという懸念が一般的です。したがって、適切なプロセスと適切なツールでバックアップすると、無駄なプロセスに時間を費やしていないことを認識しながら、コードの品質を改善できる測定可能な機能が好きです。 編集：これまでのところ私が答えから持っているもの： コードレビューは、テストの品質を確保するためにテストをカバーする必要があります Test First戦略は、事実の後に書かれたテストを回避して、カバレッジを単純に増加させるのに役立ちます％ 単純なステートメント/行以外のテスト基準をカバーする代替ツールの探索 カバーされたコード/見つかったバグの数の分析は、カバレッジの重要性を評価し、より良いケースを作るのに役立ちます 最も重要なことは、正しいことを行い、彼らの信念のために戦うというチームのインプットを信頼することです。 対象ブロック/テスト数-議論の余地あり これまで素晴らしい答えをありがとう。本当に感謝しています。このスレッドは、その能力を持つブレインストーミングの時間よりも優れています。