API コード カバレッジの具体的な目標数を知りたい人に、どのような数字を付けますか?
更新：明確にするために、ステートメント/ラインコードのカバレッジ。具体的な数字はあまり意味がないことはわかっていますが、これは、具体的な数字はあまり意味がなく、何があっても数字を取得することを主張しているという状況のためのものです。API/SDK を具体的に書いたのは、より多くのインターフェイスが公開されているライブラリとは対照的に、アプリケーション/GUI レベルのソフトウェアでは、コード カバレッジが低い方が受け入れられると考える人がいるからです。
たとえば、関数が実行されたかどうかなど、「関数カバレッジ」を提供するコード カバレッジ ツールを入手できます。API のすべての機能がカバーされていると主張したいと思います。
API の実装内の行のカバレッジは別の問題です。行またはステートメントと合計サイズに基づいて、70 ～ 80% の範囲で撮影することをお勧めします。
PHP を使用している場合は、80% が適切な推奨事項のようです: http://jordionsoftware.blogspot.com/2009/09/code-coverage-targets.html
コード カバレッジのことは忘れてください。これは単なる数値であり、コードをテストするときに注目すべきではありません。シナリオに焦点を当て、高品質の API を提供する必要があります。これは修辞的なでたらめに聞こえるかもしれませんが、考え方をコード カバレッジからシナリオに変える必要があります。API が処理しようとしている多くのシナリオをテストしていますか?
コード カバレッジは、いくつかのシナリオが欠けていることを検出するのに役立ちます。多くの優れたシナリオを記述すれば、ほぼ 100% のカバレッジが得られますが、これも単なる数字であり、焦点を当ててはなりません。
敬具
実際、具体的な数字はあまり意味がありません。
同等のケースが 14 個ある場合、14 個すべてをテストしないと、テストでエラーが発生する可能性が高くなりますか? 失敗することが不可能な境界チェックがある場合はどうすればよいでしょうか (そのような場合は、説明的な例外をスローして、開発スタッフに電子メールで送信するのが好きです)。
すべての論理パスがカバーされていることを確認することをお勧めします。
より詳細な回答については、この (非常によく似た) 質問を参照してください。
API の各部分を調べて、実際には重要でなく 20% 以上必要でない部分と、非常に重要で 90% を超える必要がある部分を判断する必要があるというアドバイスを提供します。
CRAP を見てみましょう。カバレッジと複雑さの分析が組み合わされています。Java の場合、Crap4J実装があります。ここでブログを書いた Crap4Net をまとめています。
http://www.atalasoft.com/cs/blogs/insertqualityhere/archive/2008/03/28/crap4j-port-to-net.aspx
アイデアは、小さくて単純なメソッドがある場合、またはより複雑なメソッドが十分にカバーされている場合に、適切な数値が得られるということです。