最小测试覆盖：核心逻辑 70% 的务实线

背景与问题

「テストをどれだけ書くか」——100% は神話、ゼロは危険。solo の現実解として業界コンセンサスの範囲と、何をテストするかの優先順位を整理。

発見

（出典はいずれも 2026-09-20 アクセス）

• 事実（r/ExperiencedDevs 2025-10）：規律あるチームでユニットテストはコアロジックの 60-80%。
• 事実（Qt 2025-09）：70% がよくある最低ライン——コア機能は触れるがエッジケースとエラー経路は未テスト。
• 事実（Microsoft Q&Aほか）：最低 60-70% を推奨する声が複数——0→70% で bug 検出効果が急上昇し、80% 以降は逓減。
• 事実（DaedTech の警告）：% の義務化は Goodhart 法則（目標達成のためだけの無意味テストを生む）——カバレッジは目標でなく診断ツール。
• 推测：solo の「テストを書かない」言い訳は「全部は無理」——コアロジックだけ 70% という狭い約束なら現実的（UI・glue は対象外）。

結論

1. 目標設定：コアロジック（計算/状態遷移/検証）のみ 70%。UI・glue・設定は対象外と明言して心を守る。
2. 優先順位はリスク順：①お金・データ損失系 ②ユーザー入力の検証 ③純関数——getter・設定コードは書かない。
3. カバレッジは診断ツール：月次でカバレッジレポートを見て「未テストの重要ロジック」を探す（数字の追試をしない）。
4. 境界テスト（opc-boundary-date-testing）を最初に書く：DST/月末/閏日の境界は unit テストの費用対効果が最も高い領域。

待办 / 下次继续

• 自社コアモジュールの現カバレッジを測定（0 でも記録）。
  
• 「お金・データ損失系」のテスト 3 件を書く。
  

关联

opc-boundary-date-testing opc-db-migration-safety opc-receipt-validation-minimum opc-release-precheck-5min