挨拶
株式会社アールピーシーで開発業務をメインに行っている牧野といいます。
今回、SpringBootでの自動テストをテーマに記事を投稿していきます。
以前投稿された【Spring Boot】個人的に推奨するディレクトリ／ファイル構成を参考にしたディレクトリ構成でのソースコードも紹介するので興味がわいたら是非見ていってください。
なぜ@SpringBootTestを“使わない”ことをテーマにしたのか
Spring Boot の自動テストといえば、まず最初に思い浮かぶのが@SpringBootTest。
確かにアプリ全体を起動してテストできる便利なアノテーションですが、「スピード」「外部依存」など、現場では悩まされるポイントも多くあります。
この記事では、あえて@SpringBootTestを使わない自動テストという逆張りのテーマを取り上げることで、
「どんなメリットがあるのか？」「逆に困るポイントは？」といった部分を深掘りしようと思います。
普段なんとなく@SpringBootTestを付けている方や、@SpringBootTestで十分だと考えている方も「へぇ、こういう考え方もあるんだ」程度に見ていただけると幸いです。
◎メリット
1. テスト実行が圧倒的に速い
-
@SpringBootTestはアプリ全体を起動するため、大きいプロジェクトだと初期化だけで時間がかかります。 - それに対して、
@SpringBootTestを使用しないテストはアプリ全体を起動しないため 純粋なクラス単位（ユニットテスト） として高速に実行できます。
→開発スピードのアップに加え、CI/CD等で自動テストを実行する際の高速化も狙えます。
2. テストの独立性・明確性が高い
- SpringBootの設定やDIに依存せず、クラス単体のロジックを明示的にテストできる。
→ 問題発生時に原因を追いやすい。
3. 外部依存を自由にモックできる
-
@MockやMockitoなどを使い、DB・APIなどの依存をモック化できる。
→ DBや外部APIからの取得結果をモック化することで、自前で実装したロジック部分だけを検証可能。
→ 実際のDB、APIにはリクエストしないので大規模プロジェクトの場合、他開発者への影響がない。
4. 軽量でメモリ消費が少ない
- コンテナやWebサーバを起動しないため、リソース消費が少なく、大量テストに向いている。
× デメリット
1. DIや設定の確認ができない
- Springコンテナを起動しないため、以下のようなテストケースは検証できない。
- Bean定義ミス
- コンポーネントスキャン漏れ
-
application.ymlなどの設定反映 - RESTAPIの場合、実際に返却されるレスポンスの内容
→ 次のステップのテスト(結合テスト)等で検証する必要がある。
2. テストコードがやや冗長になりやすい
- Springが依存を自動注入してくれないため、コンストラクタやモックを手動で生成・注入する必要がある。
3. 環境依存の部分を再現しづらい
-
@Valueや@ConfigurationPropertiesなどの設定値をテストする時に再現するのが手間。
→ 実運用環境に近い挙動を確認しにくい。
4. やや学習コストが高い
- 依存の注入を手動で行い、実際の挙動をモックで再現しないといけないため難易度が高い。
- JUnit、Mockitoなどテストのために追加で学習を行わなければいけない。
💡 まとめ表
| 観点 |
@SpringBootTest使わない |
@SpringBootTestを使う |
|---|---|---|
| テスト速度 | 速い | 遅い |
| 検証範囲 | 単体テスト向け | 結合/統合テスト向け |
| 外部依存モック化 | 容易（Mockitoなど） | 難しい（実Bean起動） |
| 設定反映 | 手動（自前で実装） | 自動（application.yml等） |
| デバッグ容易さ | 問題箇所が明確 | 原因が複雑化しやすい |