# バッチ設計書 27-test-reflection

## 概要

本ドキュメントは、clojure-lspプロジェクトにおけるリフレクション警告テストバッチ（test-reflection）の設計を記載したものである。

### 本バッチの処理概要

本バッチは、clojure-lspのコードにリフレクション警告が存在しないことを検証する処理である。CLIモジュールのメインクラスをロードし、その過程で発生するリフレクション警告を検出してテストの成否を判定する。

**業務上の目的・背景**：clojure-lspはGraalVMでネイティブイメージにコンパイルされる。Clojureコードでリフレクションが発生すると、GraalVMはその呼び出し先を静的に解決できず、native-imageのビルド時に問題が発生する可能性がある。リフレクション警告を事前に検出し排除することで、ネイティブイメージのビルド成功率を高め、実行時パフォーマンスも向上させることができる。

**バッチの実行タイミング**：testバッチの一部として最初に実行される。また、CI/CDパイプラインでプルリクエストやコミット時に自動実行される。単独で実行することも可能。

**主要な処理内容**：
1. cliディレクトリで clojure コマンドを実行
2. `-M:dev` エイリアスで開発環境を有効化
3. `clojure-lsp.main` 名前空間を require
4. 標準エラー出力をキャプチャしてリフレクション警告をチェック
5. "Reflection warning" 文字列が含まれていればテスト失敗

**前後の処理との関連**：testバッチの最初のサブタスクとして実行される。この検証に失敗した場合、後続のtest-libおよびtest-cliは実行されない。native-cliバッチの成功に直接関係する重要な検証である。

**影響範囲**：ファイルシステムへの永続的な変更は行わない。検証結果が標準出力に出力される。

## バッチ種別

テスト処理 / 品質検証

## 実行スケジュール

| 項目 | 内容 |
|-----|------|
| 実行頻度 | 随時（開発時）/ コミット毎（CI/CD） |
| 実行時刻 | 指定なし |
| 実行曜日 | 指定なし |
| 実行日 | 指定なし |
| トリガー | 手動（bb test-reflection）またはCI/CD |

## 実行条件

### 前提条件

| 条件 | 説明 |
|-----|------|
| JDK | Java Development Kit がインストールされていること |
| Babashka | bb コマンドが利用可能であること |
| Clojure CLI | clojure コマンドが利用可能であること |
| 依存関係 | cli/deps.edn に定義された依存関係が解決可能であること |

### 実行可否判定

特別な実行可否判定は行わない。前提条件が満たされていれば実行可能である。

## 入力仕様

### 入力パラメータ

| パラメータ名 | 型 | 必須 | デフォルト値 | 説明 |
|-------------|-----|-----|-------------|------|
| なし | - | - | - | コマンドラインパラメータは不要 |

### 入力データソース

| データソース | 形式 | 説明 |
|-------------|------|------|
| cli/src/**/*.clj | Clojureソースコード | 検証対象のCLIモジュールコード |
| lib/src/**/*.clj | Clojureソースコード | 検証対象のlibモジュールコード |
| cli/deps.edn | EDN | 依存関係定義（:dev エイリアス含む） |

## 出力仕様

### 出力データ

| 出力先 | 形式 | 説明 |
|-------|------|------|
| 標準出力 | テキスト | 警告メッセージ（存在する場合） |
| 終了コード | 整数 | 0=警告なし、1=警告あり（AssertionError） |

### 出力ファイル仕様

ファイル出力は行わない。

## 処理フロー

### 処理シーケンス

```
1. Clojure CLI実行
   └─ cliディレクトリで clojure コマンドを実行
   └─ -M:dev エイリアスを使用
   └─ -e "(require '[clojure-lsp.main])" を実行
   └─ :continue true で終了コードを無視
   └─ :err :string で標準エラーをキャプチャ

2. 標準エラー出力の取得
   └─ 実行結果から :err キーで標準エラー文字列を取得

3. 空白チェック
   └─ 標準エラーが空でない場合は警告を出力

4. リフレクション警告チェック
   └─ 標準エラーに "Reflection warning" が含まれるかチェック
   └─ 含まれる場合は assert で失敗

5. 終了
   └─ assert成功時は終了コード0
   └─ assert失敗時はAssertionErrorで終了
```

### フローチャート

```mermaid
flowchart TD
    A[バッチ開始] --> B[clojure -M:dev -e require実行]
    B --> C[標準エラー出力をキャプチャ]
    C --> D{標準エラーが空?}
    D -->|No| E[警告メッセージを出力]
    D -->|Yes| F{Reflection warning含む?}
    E --> F
    F -->|Yes| G[AssertionErrorで失敗]
    F -->|No| H[終了コード0で成功]
```

## データベース操作仕様

### 操作別データベース影響一覧

本バッチはデータベースを使用しない。

| 処理 | 対象テーブル | 操作種別 | 概要 |
|-----|-------------|---------|------|
| N/A | N/A | N/A | N/A |

### テーブル別操作詳細

該当なし。

## エラー処理

### エラーケース一覧

| エラーコード | エラー種別 | 発生条件 | 対処方法 |
|------------|----------|---------|---------|
| 1 | AssertionError | リフレクション警告が検出された | 警告箇所に型ヒントを追加 |
| - | 依存関係エラー | 必要なライブラリが見つからない | deps.edn を確認し依存関係を解決 |
| - | コンパイルエラー | ソースコードに構文エラー | ソースコードを修正 |

### リトライ仕様

| 項目 | 内容 |
|-----|------|
| リトライ回数 | 0（自動リトライなし） |
| リトライ間隔 | N/A |
| リトライ対象エラー | N/A |

### 障害時対応

1. 出力されたリフレクション警告メッセージを確認
2. 警告が発生しているソースファイルと行番号を特定
3. 該当箇所に適切な型ヒント（^ClassName）を追加
4. 再度テストを実行して警告が解消されたことを確認

## トランザクション仕様

| 項目 | 内容 |
|-----|------|
| トランザクション範囲 | N/A |
| コミットタイミング | N/A |
| ロールバック条件 | N/A |

## パフォーマンス要件

| 項目 | 内容 |
|-----|------|
| 想定処理件数 | 全ソースコードのロード1回 |
| 目標処理時間 | 1分以内 |
| メモリ使用量上限 | JVMデフォルト |

## 排他制御

同一プロジェクトディレクトリでの同時実行は可能。

## ログ出力

| ログ種別 | 出力タイミング | 出力内容 |
|---------|--------------|---------|
| 開始ログ | なし | - |
| 進捗ログ | なし | - |
| 終了ログ | なし | - |
| 警告ログ | 警告検出時 | 標準エラーの内容 |
| エラーログ | テスト失敗時 | AssertionError |

## 監視・アラート

| 監視項目 | 閾値 | アラート先 |
|---------|-----|----------|
| 終了コード | 0以外 | CI/CDシステム |
| 処理時間 | 3分 | CI/CDシステム |

## 備考

- リフレクション警告の一般的な原因：
  - Javaメソッド呼び出し時の型が不明確
  - インターフェース/プロトコルメソッドの呼び出し
  - 動的に解決されるシンボル
- 型ヒントの例：
  ```clojure
  ;; Before (警告あり)
  (.getName some-object)

  ;; After (警告なし)
  (.getName ^Class some-object)
  ```
- `*warn-on-reflection*` はプロジェクト全体で `true` に設定されている
- このテストはコードの実行ではなく、コードのロードのみを行う
- testバッチで最初に実行される理由は、ネイティブイメージビルドの成功に直結するため
