背景

リアーキテクチャ開始時に ロンドン派 のテスト手法を導入しました（当時はテストの「流派」自体を知りませんでした）。
スキルにばらつきのある約 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 % を目指す	日付・数値変換などの共通処理

コメント歓迎！
実際にデトロイト派＋バッチ開発で運用している方のフィードバックをお待ちしています 🙌