背景
リアーキテクチャ開始時に ロンドン派 のテスト手法を導入しました（当時はテストの「流派」自体を知りませんでした）。
スキルにばらつきのある約 20 名のメンバー全員で C1 カバレッジ 100 % を目標に邁進した結果、基準が明確でチーム全体に浸透しやすかった点は大きな収穫でした。
しかし開発開始から半年後、「デトロイト派のほうがテスト設計に向いている」というポッドキャストを聞き、
やっぱりデトロイト派で書き直したい…
という思いが募ります。とはいえ途中で方針転換するのは現実的ではなく、リアーキ期間中は ロンドン派 × C1 100 % のまま走り切りました。
その一年後、バッチ処理のリアーキテクチャが始動し「今度こそデトロイト派で！」と決意。ところが――
- どのクラスを対象にどの粒度まで書くのか
- 何をもって十分と判断するのか
といった基準が曖昧で、チームに落とし込むのが難航しました。
そこで「これなら回せるはず」という 指標とガイドライン を自分なりに策定しました。本記事ではその内容を共有します。すでにデトロイト派でテストを書いている方は、ぜひご意見・ご指摘いただけると幸いです。
ふるまいテストとは？
-
バッチ仕様書・画面仕様書 に記載された挙動を丸ごとテストで再現し、
項目ごとの網羅 も 抽出条件の網羅 も担保するアプローチ。 - “クラス単体” ではなく ユースケース（ふるまい） を丸ごと検証するのが特徴。
レイヤー別テスト基準
| レイヤー | 方針 | 補足 |
|---|---|---|
| Tasklet / Chunk モデル (Reader → Processor → Writer) | - Tasklet から実行して “バッチ全体のふるまい” をテスト - 仕様書を網羅するテストケースのみを書く（クラス内部の全分岐網羅はしない） |
例外系・境界値も ユースケース視点 で網羅する |
| Service | - ふるまいテストを実行して C1 ≥ 90 % なら 追加の Service テストは不要 - C1 ＜ 90 % の場合は テスト or プロダクトコードを見直す - 仕様不足？ 不要なコード？ を判断 - ふるまいテストで通しづらい必須分岐のみ Mock 付き Service テスト を追加 |
“カバレッジ不足 ＝ 追加テスト” にしない。まず 仕様と実装のズレ を疑う |
| Logic クラス | - 1 バッチ限定で参照される場合：Tasklet 経由のふるまいテストで十分 - 複数バッチ／複数機能から参照される場合：従来通り Mock を使い C1 100 % を目指す |
再利用ロジックは単体で堅牢に |
| DAO | - これまで通り SQL の網羅テスト を実施 | SQL の分岐・結合条件をすべて確認 |
| Utility | - 従来通り Mock を使い C1 100 % を目指す | 日付・数値変換などの共通処理 |
運用上のポイント
-
“まずふるまい” → 足りなければレイヤーテスト
迷ったらユースケース網羅を優先し、カバレッジ不足時のみ補完。 -
カバレッジは 指標、目的ではない
C1 100 % を目指すのはコード品質より“テスト漏れ検知”が目的。 -
仕様書とテストケースを常にリンク
テスト追加時は仕様書に行番号や ID を追記し、レビュアーが追いやすくする。
まとめ
- Tasklet でバッチ全体のふるまいを検証
- C1 カバレッジ 90 % を閾値に 追加テスト or コード見直し
- 再利用ロジック・Utility・DAO は 単体テストで堅牢に
コメント歓迎！
実際にデトロイト派＋バッチ開発で運用している方のフィードバックをお待ちしています 🙌