# テスト方針書

## 概要

本ドキュメントは、D言語製LSP（Language Server Protocol）サーバー **serve-d**（v0.8.0-beta.18）のテスト方針を定義する。serve-dは複数のサブパッケージ（http, protocol, lsp, serverbase, dcd, workspace-d）で構成されており、各レイヤーに応じたテスト戦略を策定する。

## テスト戦略

### テストレベル

| レベル | 目的 | 担当 |
| --- | --- | --- |
| 単体テスト | 各モジュール・関数単位の動作検証。ソースコード内の`unittest`ブロックにより、DDoc処理、URI変換、JSON操作、インポート解析、スニペットフォーマット等の個別ロジックを検証する | 開発者（各モジュール担当者） |
| 結合テスト | サブパッケージ間・外部ツール（DCD, dfmt, D-Scanner, DUB）との連携動作を検証。`test/tc_*`ディレクトリ内の8テストケースにより、DUBプロジェクト操作、ファイルシステムワークスペース、インターフェース自動実装、リンター統合、フォーマッタ統合等を検証する | 開発者（統合担当者） |
| システムテスト | serve-dプロセス全体の起動・終了・LSP通信を検証。`tc_as_a_exe`テストケースでserve-dをプロセスとして起動し、LSPプロトコルの`initialize`/`shutdown`/`exit`シーケンスを検証する。`null_server_test`ではJSON-RPCの各種メソッド呼び出し、エラーハンドリング、部分結果、通知を検証する | 開発者（E2E担当者） |
| 受入テスト | 対象エディタ（VS Code + code-d拡張等）でのIDE機能動作確認。自動補完、定義ジャンプ、リファクタリング、診断表示等のエンドユーザー機能を手動で確認する | QA担当者・リリースマネージャ |

### テスト種別

| 種別 | 概要 | 実施タイミング |
| --- | --- | --- |
| 機能テスト | LSPプロトコルの各メソッド（completion, definition, references, rename, formatting, code actions, inlay hints等）が仕様通りに動作するか検証 | コミット時（CI自動実行）、プルリクエスト時 |
| 性能テスト | 大規模D言語プロジェクトでの応答速度（補完、定義ジャンプ等）、メモリ使用量の確認。CI上のタイムアウト設定（単体テスト30分、結合テスト30分）により異常な性能劣化を検知する | ナイトリービルド時、リリース前 |
| セキュリティテスト | HTTP経由のDCDダウンロード（httpサブパッケージ）のTLS検証、ファイルパストラバーサル防止、不正JSON-RPCリクエストへの耐性を確認 | リリース前 |

## テスト環境

| 環境 | 用途 | 構成 |
| --- | --- | --- |
| ローカル開発環境 | 開発者によるテスト実行・デバッグ | DMD/LDC2コンパイラ、DUBビルドシステム、VS Code + code-d（`.vscode/launch.json`でGDB/LLDBデバッグ対応） |
| GitHub Actions (ubuntu-22.04) | Linux CI | DMD-latest / LDC-latest、DUB、x86_64アーキテクチャ |
| GitHub Actions (macos-latest) | macOS CI | LDC-latest、DUB、x86_64 / arm64-apple-macosアーキテクチャ |
| GitHub Actions (windows-latest) | Windows CI | LDC-latest、DUB、x86 / x86_64アーキテクチャ |

## テストツール

| ツール | 用途 | バージョン |
| --- | --- | --- |
| D言語組み込み `unittest` | 単体テストフレームワーク（ソースコード内`unittest`ブロック） | DMD/LDC同梱 |
| silly | ユニットテストランナー（テスト出力の整形・可視化） | ~>1.1.1 |
| DUB | ビルド・テスト実行（`dub test`コマンド） | 最新安定版 |
| DCD (D Completion Daemon) | 結合テスト時の補完・定義ジャンプ検証に使用 | テスト実行時に自動ダウンロード |
| dfmt | 結合テスト時のコードフォーマット検証に使用 | DUB依存として管理 |
| D-Scanner | 結合テスト時のリント・シンボル検索検証に使用 | DUB依存として管理 |
| GitHub Actions | CI/CDパイプラインでのテスト自動実行 | - |

## カバレッジ目標

| 対象 | 目標値 |
| --- | --- |
| 行カバレッジ | 未設定（現在カバレッジ計測は未導入） |
| 分岐カバレッジ | 未設定（現在カバレッジ計測は未導入） |

> **注記**: 現在のプロジェクトではD言語の`-cov`フラグや外部カバレッジツール（lcov, gcov等）によるカバレッジ計測は導入されていない。今後の改善として、CIパイプラインへのカバレッジ計測導入を推奨する。

## テストデータ

テストデータは以下の方針で管理する：

- **単体テスト用データ**: `test/data/`ディレクトリに格納。D言語ソースファイル内に`__EOF__`マーカーで期待値を記述する形式を採用し、テストコードとテストデータの対応関係を明確にする
  - `test/data/list_definition/` -- 定義一覧テスト用（`_basic.d`, `_verbose.d`, `static_ctors.d`）
  - `test/data/snippet_info/` -- スニペット情報テスト用（`_basic.d`, `dot_exception.d`, `identifiers.d`, `traits.d`）
- **結合テスト用データ**: 各テストケースディレクトリ内に配置。`test/tc_implement_interface/tests/`にはインターフェース実装の入力ファイル（`.d`）と期待出力ファイル（`.d.expected`）のペアを格納
- **E2Eテスト用データ**: `test/tc_as_a_exe/template/`にDUBプロジェクトテンプレートを配置し、テスト実行時に一時ワークスペースとしてコピーして使用
- **外部ツールバイナリ**: `test/data/dcd/download_dcd.d`スクリプトにより、DCD依存テスト（`.needs_dcd`マーカーファイルで識別）の実行前にDCDバイナリを自動ダウンロード

## 不具合管理

- **課題追跡**: GitHubのIssuesを使用して不具合を管理する
- **不具合報告の流れ**:
  1. CI/ローカルテストで不具合を検出
  2. GitHub Issueを作成（再現手順、期待結果、実際の結果を記載）
  3. 修正ブランチを作成し、プルリクエストを提出
  4. CIテストが全てパスすることを確認後、マージ
- **優先度分類**: LSP通信のクラッシュ・ハングは最優先、機能不具合は通常優先、表示上の問題は低優先

## CI/CD連携

### ワークフロー構成

3つのGitHub Actionsワークフローでテストを自動化している：

#### 1. `unittest.yml`（ユニットテスト・結合テスト）
- **トリガー**: `master`ブランチへのpush、プルリクエスト
- **マトリクス**: 3 OS（Ubuntu 22.04, Windows, macOS）× 2コンパイラ（DMD-latest, LDC-latest）
  - Windows/macOSではDMD-latestを除外（LDC-latestのみ）
- **実行順序**:
  1. `dub test :workspace-d`（30分タイムアウト）
  2. `dub test :protocol`（10分タイムアウト）
  3. `dub test :dcd`（5分タイムアウト）
  4. `dub test :lsp`（10分タイムアウト）
  5. `dub test :serverbase`（10分タイムアウト）
  6. `null_server`ビルド + `null_server_test` E2Eテスト
  7. `dub test`（メインパッケージ、30分タイムアウト）
  8. `./runtests.sh`（スタンドアロン結合テスト、30分タイムアウト）

#### 2. `nightly.yml`（ナイトリービルド）
- **トリガー**: 毎日 UTC 02:00（cronスケジュール）、手動実行
- テスト実行後にクロスプラットフォームビルドを行い、GitHub Releasesにバイナリをアップロード

#### 3. `releases.yml`（正式リリース）
- **トリガー**: GitHubリリース公開時
- テスト実行後にビルド、`ci/validate_version.d`によるバージョン整合性検証、バイナリアップロード

### テスト実行スクリプト

| スクリプト | 用途 |
| --- | --- |
| `test.bat` / `test.sh` | ローカルでの全サブパッケージテスト一括実行 |
| `test/runtests.sh` | 結合テストの順次実行（serve-dリリースビルド後、`tc_*`ディレクトリを走査） |
| `ci/build.sh` / `ci/build.bat` | CI用ビルドスクリプト（LDC2、strip、アーカイブ作成） |
| `ci/validate_version.d` | リリース時のバージョン整合性検証 |

## 備考

- **テストヘルパー**: `test/tc_as_a_exe/source/tests/package.d`に`ServedTest`/`ServedInstancedTest`抽象クラスが定義されており、RPC通信・プロセス起動・一時ワークスペース管理等のE2Eテスト共通基盤を提供する
- **workspace-dテストユーティリティ**: `workspace-d/source/workspaced/helpers.d`に`makeTemporaryTestingWorkspace`（一時ワークスペース作成）、`runTestDataFileTests`（テストデータファイル読み込み・実行）等のヘルパー関数が実装されている
- **旧CI設定**: workspace-dサブパッケージには旧Travis CI設定（`.travis.yml`）が残存しているが、現在はGitHub Actionsに移行済み
- **対応プラットフォーム**: Linux (x86_64), macOS (x86_64, arm64), Windows (x86, x86_64)の3プラットフォームでテストを実施
- **カバレッジ改善提案**: D言語の`-cov`フラグまたは外部ツールを用いたカバレッジ計測のCI導入を検討すべきである
