リポジトリのDBエラー分岐はキャンセル済みcontextで網羅する
テスト
設計判断
リポジトリ/データアクセス層の書き込み・読み取りメソッドにある if err != nil { return ... } のエラー分岐は、正常系の統合テストでは到達せず、関数カバレッジが頭打ち(典型的には70%前後)になる。実 DB を相手にすると意図的にエラーを起こしにくいのが原因。
手法: あらかじめキャンセルした context を渡すと、ドライバが context のキャンセルを尊重してクエリ実行時にエラーを返すため、SQL 実行を伴う各メソッドのエラー分岐を低コストで通せる。
設計のコツ:
- パッケージごとに「キャンセル済み context テスト」を1本用意し、SQL を実行する全メソッド(Find/List/Store/Update/Upsert/Delete など)を列挙してそれぞれ error 返却をアサートする。1メソッドだけ通して満足しないこと。
- 渡す引数は FK 整合などを満たす必要はない。キャンセルはクエリ実行前後で効くため、存在しない ID やダミー値でよい(コンパイルが通る最小限の構造体で十分)。
- 空スライスの一括 INSERT など、入力が空だと SQL を発行せず早期 return する実装は、context のキャンセルより前に抜けてエラーにならない。非空の入力を渡す。
限界と補完: この手法が検証するのは「エラーを握りつぶさず伝播するか」だけで、エラー時の個別ハンドリング(ログ整形、リトライ、特定エラーの変換)の正しさまでは見ない。分岐網羅の底上げとして使い、意味のある異常系は別途書く。
適用条件: context を第一引数で受け取り、その context をクエリ実行へ渡すデータアクセス層全般(Go の database/sql 系 ORM など)。