次のコードは、オブジェクトから別のフィールドにいくつかのフィールドをマップし、値をコピーします。
//Function params
var source= {"f1": "v1", "f2": "v2", "f3":"v3"};
var fieldsMapping = {"f1": "c1", "f2":"c2"};
//function definition starts
var copiedObj = {};
for (var name in source) {
if (source.hasOwnProperty(name)) { //Line X
if(fieldsMapping[name]){
copiedObj[fieldsMapping[name]] = source[name];
}
}
}
console.log(copiedObj); //outputs {c1: "v1", c2: "v2"}
この関数のテストケースをで作成しました。jestラインカバレッジは100％ですが、ブランチカバレッジの表示Line Xはカバーされていません。あたりとして標準で同様のTSLint、for-inループが続くべきですif condition。
誰かbranch coverageがこれのために増やすためにテストケースを持つ方法について提案できますか？
余分なものifは、コードの堅牢性のためです。このような堅牢性チェックは、賢明な方法でテストすることはできません。これは、コードの他のさまざまな部分でも発生しswitchます。これは、考えられるすべてのケースが明示的にカバーされ、例外をスローするか、この「不可能な」状況を処理するためだけにデフォルトのケースが追加されるステートメントでよく発生します。または、コードに追加されたアサーションステートメントについて考えてみてください。アサーションが失敗することはないため、厳密に言えば、アサーションステートメント内に隠されているelseブランチをカバーすることはできません。アサーション内の式が適切であることをどのようにテストしますか。あなたが望む問題を実際に検出しますか？
このような堅牢性コードとアサーションを削除することは、将来の変更による望ましくない副作用の検出にも役立つため、お勧めできません。最終的には、コードのどのステートメント/ブランチなどを実際にカバーする必要があり、どれをカバーしないかについて、十分な情報に基づいて決定する必要があります（全体のパーセンテージだけでなく、カバレッジレポートを詳細に確認することによって）。
また、最後に、コードカバレッジが高いからといって、テストスイートの品質が高いとは限らないことに注意してください。テストスイートは、存在する可能性のあるコードのバグを検出する場合、高品質です。潜在的なバグを検出しない100％のカバレッジのテストスイートを作成できます。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加