テストで埋まらない条件分岐（特に if x == nil やエラーハンドリングなどの防御コード）にぶつかったとき、「カバレッジが伸びない」という表面だけで放置せず、なぜ到達できないのかを必ず分類するとバグを拾える。

3 つに分ける:

1. 真に到達不能な防御コード（crypto/rand 失敗、上位が既に同等の検査をしていて冷長な二重ガードなど）→ 無理に埋めず理由を添えて残す。テストのために本番コードを歪めない。
2. 実は到達可能だがテストがないだけ→ 普通にテストを追加する。
3. 「到達すると壊れる」から書けない→ これが実バグ。分岐内で panic・誤った返却値・無限ループ等が起きるため「到達させるテストが書けない」状態になっている。修正してからテストを追加する。

具体例（よくある型）: 「見つからないとき nil を返す」find 関数の直後で if x == nil { logger.Error(msg, nil); return err } のようなコードは、(a) ログラッパーが err を無条件に err.Error() していると nil 渡しで panic、(b) return err が err==nil なので「not-found なのに成功を返す」論理バグ、の 2 重に壊れていることがある。この分岐が「テストで埋まらなかった」正体。

予防策:

• エラーを受け取るログラッパー関数は nil でガードする（err != nil のときだけ err.Error() を呼ぶ）。一度入れると、同種の nil 渡しが他にあっても panic クラスを一括で潰せる。
• not-found は nil(成功) ではなく明示的な not-found エラーを返す。
• 全コールサイトを横断で grep（例: logger.Error(... , nil)）して同種パターンを洗い出す。

検証方法: 修正後は分岐が到達可能になるので、そのケース（not-found・該当エラー）のテストを追加して回帰を固定する。ログラッパーの nil ガードは NotPanics で振る舞いを固定できる。

適用条件: カバレッジを上げる作業全般。「未到達だからテストを足す」という作業の中で、未到達の理由を詰めると品質バグ発見に転じる。