記事へのコメント21

    • 注目コメント
    • 新着コメント
    pplaceCEO
    低いときは「テストコードが足りない」となるだけ。 高ければ何かが保証されているかは「テストコードのほうの質」次第。 値自体はは技術領域によってもだいぶ異なる。

    その他
    fujiriko59
    カバレッジ100%ってアプリケーションのIOだけではなく(その時点での)実装をテストコードに落とし込まないと達成が不可能で、実装内容とテストコードとが密になりすぎるからやめた方がいいと思う

    その他
    nihonbuson
    大体同意。「カバレッジが100%になったとしても仕様の漏れは検知できない場合がある」は念頭に置いた方が良いと思ってる。あと、個人的にオススメの目標は、「コミット時にカバレッジが下がらないこと」です。

    その他
    onesplat
    このトピックでベン図書くバカおる?

    その他
    mak_in
    mak_in カバレッジ100%は品質を100%担保するわけではなく、品質をある程度担保する。一方で、概ねカバレッジが高い方が品質は担保しやすいが、100%に近づくにつれてコスパが悪くなるので、それを調整してくのよ

    2024/09/15 リンク

    その他
    dot
    dot 納品条件でカバレッジC1で100%という仕事をしたことあるけど、カバレッジを保持するためだけのプロダクトコードにしたり、テストコードを書くことに不毛さを感じたし、もうやりたくはないなとは思った。

    2024/09/15 リンク

    その他
    xlc
    xlc カバレッジを100%にするためにはプログラムの書き方を変更する必要がある場合(バグでしか通らないルートとか)もあり面倒ではあるが、テストケース漏れに気づくためには有益。変な閾値を作る方が有害だと思う。

    2024/09/15 リンク

    その他
    t-murachi
    t-murachi coverageはツールであるべきなんだよね。実施したテストでは通過しないコードを検出したときに、テストが足りていない可能性について検証することができる、というのが本来の使い方。

    2024/09/15 リンク

    その他
    jssei
    機能や異常系をコード側から削りまくれば、カバレッジ100%達成しやすくなるのねーん

    その他
    phonoscopia
    予期せぬエラー用の catch とかでモックがとんでもなく面倒な場合とかは書かない(当然エラー時に別で呼ばれる処理があればそれは書く)かな。結果85〜90%程度に落ち着いたりするけどあくまで目標は100%

    その他
    taguch1
    なんで2018年のポストが???と思うけどいまだに答えが出てないのかな。自分的にはいい塩梅というか感覚値で勘所は掴んだと思う。言語化はまだw

    その他
    devrabi
    85%が目安みたいなのはセオリーだと思っていました。問題になるのは、100%じゃないとテストが弱い所を見つけるのが面倒というところですかね

    その他
    igni3
    100%にしたければテストを減らせばいいじゃない

    その他
    daishi_n
    カバレッジとテストの質(正常、準正常、異常)を分けろはわからんでもないけど、テスト項目としてはわけるからねえ

    その他
    mr_mayama
    テストの中身の方が重要

    その他
    yfukuda827
    テストカバレッジは全体を見るものですが、レビュアーの時にはカバー部分はいったん見ているので、ざっくり俯瞰するには良いと思います。数値にこだわる必要はないかなと

    その他
    n2sz
    n2sz カバレッジ100%未満でOKとする場合、走行できてないコードの品質は何で担保するのかな。

    2024/09/15 リンク

    その他
    lainof
    lainof 必ずしも100%にする必要はないけど、レアケースでもない処理がテストできてなければテストの品質が低い可能性が高いので未実行の処理内容は確認した方が良い。そもそもテストでは設計した品質以上に品質は上がらない

    2024/09/15 リンク

    その他
    toro-chan
    toro-chan 100%って契約で決まってるからしょうがなく達成させられるイメージ。どんなに論理的に不要だろうが言う方は簡単なので無くならないのかもしれない。

    2024/09/15 リンク

    その他
    cyph
    cyph “『カバレッジが低ければ、ソースコードの品質が低い』と言える”言えなくない?テストがあることが高品質の条件であるという定義なら別だが。カバレッジが低いということは、カバレッジが低いと言うことです。

    2024/09/15 リンク

    その他
    fuji_haruka
    fuji_haruka 品質の高低みたいなバイナリで決まらないものに対して命題論理で議論するのは違和感あるけど。

    2024/09/15 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita

    皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか?少なくと...

    ブックマークしたユーザー

    • learn2025/05/30 learn
    • tmg19982024/09/17 tmg1998
    • ludwig1252024/09/17 ludwig125
    • imyutaro2024/09/17 imyutaro
    • jojo-gold-experience-12102024/09/16 jojo-gold-experience-1210
    • jori_ds2024/09/16 jori_ds
    • elwoodblues2024/09/16 elwoodblues
    • pplaceCEO2024/09/16 pplaceCEO
    • dhesusan46492024/09/16 dhesusan4649
    • fujiriko592024/09/16 fujiriko59
    • t_otoda2024/09/16 t_otoda
    • kokihonma2024/09/16 kokihonma
    • muuran162024/09/16 muuran16
    • nihonbuson2024/09/16 nihonbuson
    • masa0x802024/09/16 masa0x80
    • mikage0142024/09/16 mikage014
    • fjch2024/09/15 fjch
    • sutatin2024/09/15 sutatin
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    いま人気の記事 - 企業メディア

    企業メディアをもっと読む