リポジトリ／データアクセス層の書き込み・読み取りメソッドにある if err != nil { return ... } のエラー分岐は、正常系の統合テストでは到達せず、関数カバレッジが頭打ち（典型的には70%前後）になる。実 DB を相手にすると意図的にエラーを起こしにくいのが原因。

手法: あらかじめキャンセルした context を渡すと、ドライバが context のキャンセルを尊重してクエリ実行時にエラーを返すため、SQL 実行を伴う各メソッドのエラー分岐を低コストで通せる。

ctx, cancel := context.WithCancel(context.Background())
cancel()
_, err := repo.Find(ctx, id)   // → error
err = repo.Store(ctx, entity)   // → error
err = repo.Delete(ctx, id)      // → error

設計のコツ:

• パッケージごとに「キャンセル済み context テスト」を1本用意し、SQL を実行する全メソッド（Find/List/Store/Update/Upsert/Delete など）を列挙してそれぞれ error 返却をアサートする。1メソッドだけ通して満足しないこと。
• 渡す引数は FK 整合などを満たす必要はない。キャンセルはクエリ実行前後で効くため、存在しない ID やダミー値でよい（コンパイルが通る最小限の構造体で十分）。
• 空スライスの一括 INSERT など、入力が空だと SQL を発行せず早期 return する実装は、context のキャンセルより前に抜けてエラーにならない。非空の入力を渡す。

限界と補完: この手法が検証するのは「エラーを握りつぶさず伝播するか」だけで、エラー時の個別ハンドリング（ログ整形、リトライ、特定エラーの変換）の正しさまでは見ない。分岐網羅の底上げとして使い、意味のある異常系は別途書く。

適用条件: context を第一引数で受け取り、その context をクエリ実行へ渡すデータアクセス層全般（Go の database/sql 系 ORM など）。