C0・C1カバレッジは100%でしょ。テストが冗長に見えるのはコードがダメなせい。テストケースを増やすのも（ifを増やすとか）ダメだっていう話になる。問題はそっち。こっちではない。
テストコードもAIで書く時代だけどカバレッジ100%至上主義との不毛な戦いは終わらんな。SIer時代のExcelスクショ地獄はNG
代表的な1パターンを確認できれば十分、というのは全部書いてるのと同じなのでは
強い言葉を使うんじゃない！
Pairwiseとか直交表の話かと思ったら違った
この辺の思想のギャップがAIでさらに増幅されて実装のアウトプットの差になってきそう
単位を持った量を型に集約すると、その単位として正しい振る舞いを考えてテストケース書けば安全に扱える部品が出来上がって安心してコードを積み上げやすい。UnitTestは単体テストじゃなくて単位テストだと思ってる…
杉下右京。「全部書くんじゃぁ、ありません！！」
10年以上キャリアあってテストに対する認識この程度なの？キャッチーなタイトルでビューを稼ぎたいのかもしれないけど中身が全然「全通り書くな」じゃなかった。
他人のメモみたいな物に対してブクマで自分の意見を書くのは自由なのだけど、だとしても必要以上にケチをつける事は無いと思うんだよね。この文章を書いた人を眼の前にしても同じように失礼な物言いをするのかい？と
検証（Verification）と妥当性確認（Validation）がごっちゃになってないか。テストケースの洗い出し手法とか密度の話をしたいのかな。
そもそも本来のTDDってテストを先に書いて、それがグリーンになる、かつカバレッジロスが残らない、を目指すものじゃなかったっけ? (今どきは先にテストコードはあまり推奨されなくなったけど)
個人のメモならチラシの裏に書けば良いので全世界に公開しておいて批判することを批判するのってマヌケの極みだよね。
「費用」が無視できないレベルになってきてから判断すれば良い。AIコード生成の時代になって「費用」のうち「作成コスト」は（多くの場合は「維持コスト」も）著しく低下し、人間判断のコストが相対的に増加している
基本パターン、書いた時点で使われてる正常パターンと明確な異常パターンを最低１つ、がベースかな
id:pmint さん id:nanika-sheila さんも間違い指摘してるけど。テスト強度やレイヤーで網羅率100%厳守はあるので、"おおよそ75%程度を目安にすればよい" これはﾜﾝﾊﾟｸ過ぎる。一昔前だとwakateとか品質pmoの勉強会あったよ
間違いが許容される部分においてはそれでいいんじゃないかな／お金や時間を扱うところはそうは言っていられないので
は？//ブクマ100超えてるからなにか有用な記事なのかな？と思って読みに来たあなたへ：そういうのではないので読まなくて大丈夫です。
この気分駆動開発を最大限美化するとすれば、持続可能開発とか、現実主義開発と呼ぶのが良さそう。人によって、またその時の気分によって網羅性が変わるのはいかがなものか。
Very helpful, thank you https://windows-vps.org/
あらゆるテストはもうAiに全部面倒見てほしい
タイトルを "テストを全通り書くんじゃない！" から "テストコードをどこまで書くかを考える" に更新しました。 テストは汎用機がよかった。汎用機は統合環境ができてた。修正時の再テストが楽だった。
単体テストを全通り書くんじゃない！
C0・C1カバレッジは100%でしょ。テストが冗長に見えるのはコードがダメなせい。テストケースを増やすのも（ifを増やすとか）ダメだっていう話になる。問題はそっち。こっちではない。
テストコードもAIで書く時代だけどカバレッジ100%至上主義との不毛な戦いは終わらんな。SIer時代のExcelスクショ地獄はNG
代表的な1パターンを確認できれば十分、というのは全部書いてるのと同じなのでは
強い言葉を使うんじゃない！
Pairwiseとか直交表の話かと思ったら違った
この辺の思想のギャップがAIでさらに増幅されて実装のアウトプットの差になってきそう
単位を持った量を型に集約すると、その単位として正しい振る舞いを考えてテストケース書けば安全に扱える部品が出来上がって安心してコードを積み上げやすい。UnitTestは単体テストじゃなくて単位テストだと思ってる…
杉下右京。「全部書くんじゃぁ、ありません！！」
10年以上キャリアあってテストに対する認識この程度なの？キャッチーなタイトルでビューを稼ぎたいのかもしれないけど中身が全然「全通り書くな」じゃなかった。
他人のメモみたいな物に対してブクマで自分の意見を書くのは自由なのだけど、だとしても必要以上にケチをつける事は無いと思うんだよね。この文章を書いた人を眼の前にしても同じように失礼な物言いをするのかい？と
検証（Verification）と妥当性確認（Validation）がごっちゃになってないか。テストケースの洗い出し手法とか密度の話をしたいのかな。
そもそも本来のTDDってテストを先に書いて、それがグリーンになる、かつカバレッジロスが残らない、を目指すものじゃなかったっけ? (今どきは先にテストコードはあまり推奨されなくなったけど)
個人のメモならチラシの裏に書けば良いので全世界に公開しておいて批判することを批判するのってマヌケの極みだよね。
「費用」が無視できないレベルになってきてから判断すれば良い。AIコード生成の時代になって「費用」のうち「作成コスト」は（多くの場合は「維持コスト」も）著しく低下し、人間判断のコストが相対的に増加している
基本パターン、書いた時点で使われてる正常パターンと明確な異常パターンを最低１つ、がベースかな
id:pmint さん id:nanika-sheila さんも間違い指摘してるけど。テスト強度やレイヤーで網羅率100%厳守はあるので、"おおよそ75%程度を目安にすればよい" これはﾜﾝﾊﾟｸ過ぎる。一昔前だとwakateとか品質pmoの勉強会あったよ
間違いが許容される部分においてはそれでいいんじゃないかな／お金や時間を扱うところはそうは言っていられないので
は？//ブクマ100超えてるからなにか有用な記事なのかな？と思って読みに来たあなたへ：そういうのではないので読まなくて大丈夫です。
この気分駆動開発を最大限美化するとすれば、持続可能開発とか、現実主義開発と呼ぶのが良さそう。人によって、またその時の気分によって網羅性が変わるのはいかがなものか。
Very helpful, thank you https://windows-vps.org/
あらゆるテストはもうAiに全部面倒見てほしい
タイトルを "テストを全通り書くんじゃない！" から "テストコードをどこまで書くかを考える" に更新しました。 テストは汎用機がよかった。汎用機は統合環境ができてた。修正時の再テストが楽だった。